Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [RTG-DIR] handling module incompatibility => handling module transition

[Benoit Claise]

Replying to Jürgen, Andy, and Rob in this email.

Yes. Semantic versioning is a step in the right direction. Specifically 
for native/generated models (yes, those exist into the wild). And for 
"standard" models too. See 
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-01#section-2.1

We'll have to come to the notion of release bundle, for sure.
The "leaf tree-type" (*) is a release bundle type of metadata anyway
I was hoping that the IETF would be releasing YANG modules in bundle, 
but looking at the rate, it seems more drop by drop. Anyway, all those 
routing modules should be working together. The YANG impact analysis 
should help in checking this. See 
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=both
Btw, the "dependent" and "dependencies" are also metadata in the 
yangcatalog.org

Just saying that YANG modules "are designed and known to work together 
into meaningful packages" is interesting.
However, in the end, operators combine/test YANG modules to deploy 
services. This is Rob"s feature bundle described below. Since this 
notion of feature bundle is service specific, for service composition, 
in the end, the feature bundle is a service-specific release bundle, so 
operator specific, so orchestrator/controller specific.

I agree that semantic versioning is only part of the solution.
In OpenConfig versioning we have the concept of release bundles that 
have a semver, these contain modules that are known to work together - 
and are the base for compliance descriptions.
The individual modules semver has been useful to mark where there are 
backwards incompatible changes in an individual module.

On top of release bundles, we also have feature bundles which describe 
a particular implementation's requirements for the modules. A feature 
bundle is a description of paths within a release bundle.

We're continuing to gain experience with how well this works, but 
certainly I don't see the need for the bundles alleviating the need 
for the semantic versions for modules.
+1.

It's a matter of determining which problem we want to tackle now.

(*) https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog/

leaf tree-type {
        type enumeration {
          enum "split" {
            description
              "This module uses a split config/operational state layout.";
          }
          enum "nmda-compatible" {
            description
              "This module is compatible with the Network Management Datastores
               Architecture (NMDA) and combines config and operational state 
nodes.";
          }
          enum "transitional-extra" {
            description
              "This module is derived as a '-state' module to allow for 
transitioning
               to a full NMDA-compliant tree structure.";
          }
          enum "openconfig" {
            description
              "This module uses the Openconfig data element layout.";
          }
          enum "unclassified" {
            description
              "This module does not belong to any category or can't be 
determined.";
          }
          enum "not-applicable" {
            description
              "This module is not applicable. For example, because the YANG module 
only contains typedefs, groupings, or is a submodule";
          }
        }
        description
          "The type of data element tree used by the module as it relates to the
           Network Management Datastores Architecture.";
        reference "draft-dsdt-nmda-guidelines Guidelines for YANG Module Authors 
(NMDA)";
      }


Regards, Benoit

On Fri, 3 Nov 2017 at 11:05 Andy Bierman <a...@yumaworks.com 
<mailto:a...@yumaworks.com>> wrote:

    On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder
    <j.schoenwael...@jacobs-university.de
    <mailto:j.schoenwael...@jacobs-university.de>> wrote:

        My take here is that structured version numbers do only partially
        solve the problem. Andy's work years ago on packages offers in
        my view
        a superior foundation for a solution. Once we can bundle
        modules that
        are designed and known to work together into meaningful
        packages, then
        it may be possible to relax some of the strict RFC 7950 update
        rules.

        Once the NETMOD WG gets the work on NMDA "completed", I
        believe "YANG
        packages" are a worthwhile target to work on. There is a need
        to get
        more structure into the module space, not just additional
        structured
        version numbers.


    I agree ;-)

    It is nice to have a way to know current implementations will probably
    break if they upgrade to the new version. It is even nicer if the APIs
    are stable and don't break existing code.

    It is not encouraging that the IETF cannot produce stable YANG modules
    published in RFCs.  We expect I-Ds to ignore the YANG update rules,
    but not RFC versions.

    Since the semantic versioning is only per-module, it is not
    usefull for
    determining if module foo will work with module bar.  If it is OK
    to break backward-compatibility then it will become increasingly
    difficult to just use the latest version of a module. Real
    interoperability
    at the granularity of modules will become more difficult. YANG
    packages
    can dramatically reduce the number of API permutations.


        /js


    Andy


        On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
        > Dear all,
        >
        > Let me present this draft
        >
        https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
        >
        >                     New YANG Module Update Procedure
        >  draft-clacla-netmod-yang-model-update-01
        >
        > Abstract
        >
        >    This document specifies a new YANG module update
        procedure in case of
        >    non backward-compatible changes, as an alternative
        proposal to the
        >    YANG 1.1 specifications.  This document updates RFC 7950.
        >
        >
        > Problem statement:
        > Changing a YANG module name each time there is a non
        backward compatible
        > change (as RFC7950 requires) adds a lot of complexity to
        automation, from an
        > import and service composition point of view.
        >
        > Solution:
        > We need a different mechanism. The solution in the draft is
        based on the
        > semantic versioning YANG extension: it was proposed
        openconfig in the past
        > and is currently used by the openconfig YANG modules
        >
        > Note: there might other solutions, such as new YANG
        keywords, but at this
        > point in time, it's important to recognize that we need to
        change the way we
        > produce YANG modules at the IETF. Let's discuss on the list
        and during the
        > NETMOD meeting.
        >
        > Regards, Benoit.
        > > On 10/12/2017 3:30 PM, Benoit Claise wrote:
        > > > Hi Lou,
        > > > >
        > > > > So circling back to the original question: what do we
        do about
        > > > > the non backward-compatible module being defined in
        rfc8049bis?
        > > > >
        > > > > While being sympathetic to many of the comments made
        below as
        > > > > well as the "do over" concept, I find the comments about
        > > > > adhering to the rules of 7950 compelling - which leads to
        > > > > renaming the module in the bis to ietf-l3vpn-svc-2.
        > > > >
        > > > > It would be good to ensure that this is the consensus
        of the
        > > > > group before asking the authors make this change.
        > > > >
        > > > Since this draft is AD sponsored, I'll evaluate the
        consensus on
        > > > RFC8049bis.
        > > > Moving to ietf-l3vpn-svc-2 is the easy path not to break
        backward
        > > > compatibility. However, since ietf-l3vpn-svc is
        unimplementable (it
        > > > has broken XPATH expressions, so a compliant
        implementation is
        > > > impossible), so technically, ietf-l3vpn-svc does not
        even exist.
        > > See my message on this topic, as the IETF LC follow up.
        > >
        
https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html
        > > If a follow up is required, I propose that we use a single
        public email
        > > thread: the i...@ietf.org <mailto:i...@ietf.org>
        > >
        > > Regards, Benoit
        > > >
        > > > What NETMOD should focus on is closing on the NMDA
        transition: the
        > > > ietf-routing versus ietf-routing-2 issue.
        > > > Way bigger impact in terms of dependent YANG modules
        > > >
        > > > Regards, Benoit (as OPS AD)
        > > > See below.
        > > > >
        > > > > This change course doesn't solve the versioning issue
        discussed
        > > > > below, but this is not a new issue it's just the first
        time
        > > > > we'll actually executing the steps envisioned as part
        of the
        > > > > rules laid out in yang. My personal take away is that
        means that
        > > > > we should immediately start work on an extension
        defining along
        > > > > the lines of  ' *_obsolete|update_*' mentioned below.
        > > > >
        > > > I believe that option 1 is the more pragmatic and
        complete solution.
        > > > option 2 is just half a step in the right direction.
        > > > I believe we should discuss this topic in Singapore.
        > > >
        > > > Regards, Benoit (as individual contributor)
        > > > >
        > > > > Lou
        > > > >
        > > > > On October 8, 2017 10:59:15 AM Benoit Claise
        <bcla...@cisco.com <mailto:bcla...@cisco.com>> wrote:
        > > > >
        > > > > > Dear all,
        > > > > >
        > > > > > Focusing on draft-wu-l3sm-rfc8049bis, the big
        problem is:
        > > > > > RFC8049 is broken. The small problem is: trying to
        maintain
        > > > > > backward compatibility.
        > > > > > draft-wu-l3sm-rfc8049bis has rightly focused on the
        big problem.
        > > > > >
        > > > > > Let me extend the scope of this email thread from
        "handling
        > > > > > module incompatibility" to "handling module
        incompatibility
        > > > > > and NMDA transition".
        > > > > > As I mentioned in the past (see "semver.org
        <http://semver.org> comparison of
        > > > > > two YANG modules" email in NETMOD), I believe the
        IETF will
        > > > > > have to change its way of working in terms of backward
        > > > > > compatibility. See also the email "ietf-routing or
        > > > > > ietf-routing-2? module naming convention for NMDA
        > > > > > transition. Re: [netmod] upcoming adoptions" in NETMOD.
        > > > > >
        > > > > > However, we will have to tackle this discussion one
        day or the other:
        > > > > > - we need _an automatic way_ to make the link
        between the
        > > > > > YANG module in RFC8049 and the YANG module in
        > > > > > draft-wu-l3sm-rfc8049bis, or any non backward compatible
        > > > > > YANG modules.
        > > > > > - we need _an automatic way_ to make the link
        between the
        > > > > > YANG module in RFC8022 and the YANG module in
        > > > > > draft-acee-netmod-rfc8022bis, or any new YANG module
        names
        > > > > > used for NMDA transition.
        > > > > > Note: actually, we face two different problems.
        > > > > > draft-wu-l3sm-rfc8049bis might be declared backward
        > > > > > incompatible with RFC8049, while RFC8022bis is backward
        > > > > > compatible with RFC8022. The RFC8022bis went for a
        new YANG
        > > > > > module name ietf-routing-2 to avoid to document the
        -state
        > > > > > tree (as deprecated), based on the argument that
        > > > > > ietf-routing is not yet implemented.
        > > > > >
        > > > > > Which solutions do we have from here?
        > > > > > #1. We keep the same module name and express that
        the YANG
        > > > > > module in draft-wu-l3sm-rfc8049bis is not backward
        > > > > > compatible with the RFC8049 one. This is the
        openconfig way.
        > > > > > See draft-clacla-netmod-model-catalog (and
        > > > > > draft-openconfig-netmod-model-catalog before)
        > > > > >
        > > > > >        // extension statements
        > > > > >           extension openconfig-version {
        > > > > >             argument "semver" {
        > > > > >               yin-element false;
        > > > > >             }
        > > > > >             description
        > > > > >               "The OpenConfig version number for the
        module. This is
        > > > > >               expressed as a semantic version number
        of the form:
        > > > > >                 x.y.z
        > > > > >                where:
        > > > > >                 * x corresponds to the major version,
        > > > > >                 * y corresponds to a minor version,
        > > > > >                 * z corresponds to a patch version.
        > > > > >               This version corresponds to the model
        file within which it is
        > > > > >               defined, and does not cover the whole
        set of OpenConfig models.
        > > > > >               Where several modules are used to
        build up a single block of
        > > > > >               functionality, the same module version
        is specified across each
        > > > > >               file that makes up the module.
        > > > > >
        > > > > >               A major version number of 0 indicates
        that this model is still
        > > > > >               in development (whether within
        OpenConfig or with industry
        > > > > >               partners), and is potentially subject
        to change.
        > > > > >
        > > > > >               Following a release of major version
        1, all modules will
        > > > > >               increment major revision number where
        backwards incompatible
        > > > > >               changes to the model are made.
        > > > > >
        > > > > >               The minor version is changed when
        features are added to the
        > > > > >               model that do not impact current
        clients use of the model.
        > > > > >
        > > > > >               The patch-level version is incremented
        when non-feature changes
        > > > > >               (such as bugfixes or clarifications to
        human-readable
        > > > > >               descriptions that do not impact model
        functionality) are made
        > > > > >               that maintain backwards compatibility.
        > > > > >
        > > > > >               The version number is stored in the
        module meta-data.";
        > > > > >           }
        > > > > >
        > > > > > Similarly, we always keep the same YANG module name
        in case
        > > > > > of NMDA transition. So ietf-routing-2 should be
        changed back
        > > > > > to ietf-routing.
        > > > > > The email thread "[Rtg-dt-yang-arch] ietf-routing or
        > > > > > ietf-routing-2? module naming convention for NMDA
        > > > > > transition. Re: [netmod] upcoming adoptions" seems
        to go in
        > > > > > that direction.
        > > > > >
        > > > > > #2. Or we have a different module name, let's say
        > > > > > ietf-l3vpn-svc-2 or ietf-routing-2 but then, how do
        we make
        > > > > > the link with the previous module?
        > > > > > Then ...  What? We create extension that will link the
        > > > > > draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG
        > > > > > module? Same principle as #1, but just more complex.
        > > > > > Or we have a new YANG keyword (this implies YANG 2.0)
        > > > > >
        > > > > >     <CODE BEGINS>file"ietf-l3vpn-...@2017-09-14.yang"
        > > > > >     module ietf-l3vpn-svc-2 {
        > > > > >       yang-version 1.1;
        > > > > >       namespace
        "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
        > > > > >       prefix l3vpn-svc;
        > > > > >       *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
        > > > > >
        > > > > > And whose responsibility is this to warn/push all
        authors of
        > > > > > ietf-routing YANG modules to move to ietf-routing-2? (*)
        > > > > >
        > > > > > The following are non solution IMO:
        > > > > > - Going from the draft-wu-l3sm-rfc8049bis YANG
        _module _to
        > > > > > the draft-wu-l3sm-rfc8049bis _document _to lookup
        the IETF
        > > > > > "obsolete" flag in order to understand that the
        RFC8049 YANG
        > > > > > module is obsolete is not an automatic solution.
        > > > > > - Using the yangcatalog.org <http://yangcatalog.org>
        might be a solution as we track
        > > > > > the derived semantic, but this is just an offline trick.
        > > > > > This is not what I call "automatic way"
        > > > > > - Using the YANG module description field might be
        > > > > > interesting, but again this is not an "automatic way":
        > > > > >
        > > > > >       description
        > > > > >        "This YANG module defines a generic service
        configuration
        > > > > >         model for Layer 3 VPNs. This model is common
        across all
        > > > > >         vendor implementations. This obsoletes the
        RFC8049 YANG
        > > > > >         module, ietf-l3vpn-svc@2017-01-2";
        > > > > >       revision 2017-09-14 {
        > > > > >        description
        > > > > >     "First revision ofRFC8049
        <https://tools.ietf.org/html/rfc8049>.";
        > > > > >        reference
        > > > > >         "RFC xxxx: YANG Data Model for L3VPN Service
        Delivery";
        > > > > >
        > > > > >
        > > > > > In conclusion, I believe openconfig got this right
        and that
        > > > > > solution #1 is the solution to go ... while waiting
        for a
        > > > > > new YANG keyword in YANG 2.0
        > > > > >
        > > > > > (*) If you want to change the module from
        ietf-routing to
        > > > > > ietf-routing-2, then you should follow with all
        authors of
        > > > > > dependent modules to make sure they transition to
        > > > > > ietf-routing-2
        > > > > > In the yangcatalog.org <http://yangcatalog.org>,
        because I needed the information as
        > > > > > OPS AD, we created a small script to get that
        authors list
        > > > > > for IETF drafts. For the ietf-routing, this produces the
        > > > > > following
        > > > > > {
        > > > > >     "output": {
        > > > > >         "author-email": [
        > > > > > "draft-ietf-mpls-static-y...@ietf.org
        <mailto:draft-ietf-mpls-static-y...@ietf.org>",
        > > > > > "draft-ietf-mpls-base-y...@ietf.org
        <mailto:draft-ietf-mpls-base-y...@ietf.org>",
        > > > > > "draft-ietf-ospf-sr-y...@ietf.org
        <mailto:draft-ietf-ospf-sr-y...@ietf.org>",
        > > > > > "draft-ietf-pim-y...@ietf.org
        <mailto:draft-ietf-pim-y...@ietf.org>",
        > > > > > "draft-ietf-bier-bier-y...@ietf.org
        <mailto:draft-ietf-bier-bier-y...@ietf.org>",
        > > > > > "draft-zhang-bier-te-y...@ietf.org
        <mailto:draft-zhang-bier-te-y...@ietf.org>",
        > > > > > "draft-ietf-isis-yang-isis-...@ietf.org
        <mailto:draft-ietf-isis-yang-isis-...@ietf.org>",
        > > > > > "draft-ietf-teas-yang-rsvp...@ietf.org
        <mailto:draft-ietf-teas-yang-rsvp...@ietf.org>",
        > > > > > "draft-ietf-mpls-mldp-y...@ietf.org
        <mailto:draft-ietf-mpls-mldp-y...@ietf.org>",
        > > > > > "draft-zhao-pim-igmp-mld-snooping-y...@ietf.org
        <mailto:draft-zhao-pim-igmp-mld-snooping-y...@ietf.org>",
        > > > > > "draft-ietf-isis-sr-y...@ietf.org
        <mailto:draft-ietf-isis-sr-y...@ietf.org>",
        > > > > > "draft-acee-rtgwg-yang-rib-ext...@ietf.org
        <mailto:draft-acee-rtgwg-yang-rib-ext...@ietf.org>",
        > > > > > "draft-ietf-pim-igmp-mld-y...@ietf.org
        <mailto:draft-ietf-pim-igmp-mld-y...@ietf.org>",
        > > > > > "draft-ietf-i2rs-fb-rib-data-mo...@ietf.org
        <mailto:draft-ietf-i2rs-fb-rib-data-mo...@ietf.org>",
        > > > > > "draft-ietf-ospf-y...@ietf.org
        <mailto:draft-ietf-ospf-y...@ietf.org>",
        > > > > > "draft-ietf-rtgwg-yang-...@ietf.org
        <mailto:draft-ietf-rtgwg-yang-...@ietf.org>",
        > > > > > "draft-ietf-spring-sr-y...@ietf.org
        <mailto:draft-ietf-spring-sr-y...@ietf.org>",
        > > > > > "draft-ietf-teas-yang-r...@ietf.org
        <mailto:draft-ietf-teas-yang-r...@ietf.org>",
        > > > > > "draft-ietf-i2rs-pkt-eca-data-mo...@ietf.org
        <mailto:draft-ietf-i2rs-pkt-eca-data-mo...@ietf.org>",
        > > > > > "draft-ietf-mpls-ldp-y...@ietf.org
        <mailto:draft-ietf-mpls-ldp-y...@ietf.org>",
        > > > > > "draft-ietf-bfd-y...@ietf.org
        <mailto:draft-ietf-bfd-y...@ietf.org>",
        > > > > > "draft-ietf-pim-msdp-y...@ietf.org
        <mailto:draft-ietf-pim-msdp-y...@ietf.org>"
        > > > > >         ]
        > > > > >     }
        > > > > > }
        > > > > >
        > > > > > Fortunately, we only deal with IETF dependent YANG
        modules
        > > > > > in case of the ietf-routing. That's an easier case.
        > > > > > If we would change ietf-interfaces to
        ietf-interfaces-2, we
        > > > > > would have an cross SDO issue ... Btw, there are no
        > > > > > automatic ways to extract the authors of YANG
        modules from
        > > > > > different SDOs: it's only a metadata that that the
        different
        > > > > > SDOs should insert in the yangcatalog. So we would
        have to
        > > > > > rely on liaisons or direct emails, assuming we know the
        > > > > > authors. Time consuming, believe me.
        > > > > >
        > > > > > Regards, Benoit
        > > > > > > Hi,
        > > > > > >
        > > > > > >      As part of the my Routing Directorate review of
        > > > > > > draft-wu-l3sm-rfc8049bis I noted that there were
        several incompatible
        > > > > > > changes being made to the ietf-l3vpn-svc module
        without changing the
        > > > > > > name.  I raised this with the YANG doctors and
        others involved with the
        > > > > > > draft and it surfaced some topics which really
        should be discussed here
        > > > > > > in NetMod.
        > > > > > >
        > > > > > > The background (as explained off-list by others,
        so I hope I have it
        > > > > > > right)  is that one of the YANG Doctors noted that
        RFC8049 was broken
        > > > > > > and could not be implemented as defined, and
        therefore a fix was
        > > > > > > needed.  L3SM has concluded so the fix is in the
        individual draft
        > > > > > > draft-wu-l3sm-rfc8049bis.  Since the rfc8049
        version of ietf-l3vpn-svc
        > > > > > > module could not be implemented, the feeling by
        the YANG Dr was that
        > > > > > > even though the new module is incompatible with
        the original definition
        > > > > > > the module the rule defined in Section 11 of YANG
        1.1 (or section 10 of
        > > > > > > RFC 6020) didn't have to be followed and the same
        name could be used.
        > > > > > >
        > > > > > > In the subsequent discussion with the YANG Drs.,
        the general discussion
        > > > > > > was heading down the path of using a new module
        name, and thereby not
        > > > > > > violating YANG module update rules.  This lead us
        back to the a similar
        > > > > > > discussion we've been having in the context of
        8022bis: how best to
        > > > > > > indicate that a whole module is being obsoleted. 
        RFCs do this by adding
        > > > > > > 'metadata' to the headers, e.g., "Obsoletes:
        8049", but this doesn't
        > > > > > > help YANG tooling.  For 8022, we have one approach
        - publishing an
        > > > > > > updated rev of the original module marking all
        nodes as deprecated - but
        > > > > > > that doesn't really make sense for rfc8049bis.
        > > > > > >
        > > > > > > So the discussion for the WG is:
        > > > > > >
        > > > > > > How do we handle incompatible module changes,
        notably when one module
        > > > > > > 'obsoletes' another module --  from both the
        process and tooling
        > > > > > > perspectives?
        > > > > > >
        > > > > > > I know Benoit plans to bring in some
        thoughts/proposals, perhaps there
        > > > > > > are others.
        > > > > > >
        > > > > > > Cheers,
        > > > > > >
        > > > > > > Lou
        > > > > > >
        > > > > > > (as contributor/reviewer)
        > > > > > >
        > > > > > >
        > > > > > >
        > > > > > >
        > > >
        > >
        >

        > _______________________________________________
        > netmod mailing list
        > netmod@ietf.org <mailto:netmod@ietf.org>
        > https://www.ietf.org/mailman/listinfo/netmod


        --
        Juergen Schoenwaelder           Jacobs University Bremen gGmbH
        Phone: +49 421 200 3587 <tel:+49%20421%202003587>    Campus
        Ring 1 | 28759 Bremen | Germany
        Fax: +49 421 200 3103 <tel:+49%20421%202003103>  
         <http://www.jacobs-university.de/>

        _______________________________________________
        netmod mailing list
        netmod@ietf.org <mailto:netmod@ietf.org>
        https://www.ietf.org/mailman/listinfo/netmod

    _______________________________________________
    netmod mailing list
    netmod@ietf.org <mailto:netmod@ietf.org>
    https://www.ietf.org/mailman/listinfo/netmod


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod