Subject: [netmod] revised-datastores and commonality of schemas

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 2 Nov 2017 18:50:58 +0000

Hi guys,

Templates are something that may be problematic for this concept of common schemas across the running/candidate/intended DSes and then operational being a superset.

The <running> DS needs to have both the template itself in the schema as well as whatever nodes are used to hold 'exploded' data.  But what about intended and operational ?

For example, imagine we have the following instance data in a candidate & running DS:
1) a template that sets an admin-state leaf to 'enabled' in all interfaces
2) a set of 3 interfaces with a few leafs of config in them (address, etc)

Clearly the schema for the candidate/running DSes contain both the template and the interface schema nodes.

But does the schema for the intended DS actually have the template schema nodes ?   In theory it doesn't *need* to (since templates are exploded between running & intended), and it feels strange to have those in there, but I suppose it could have them.  If they are there, then a read of the intended would show "admin-state enabled" in the template *and* in the 3 interfaces.

Does the operational DS contain the template schema nodes ?  If yes, then I suppose we would consider all templates as 'applied' implicitly ?

Rgds,
Jason

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Robert
> Wilton
> Sent: Tuesday, October 31, 2017 10:01
> To: [email-masked]
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-
> 06.txt
> 
> So this version of the draft contains the small change that defines "datastore
> schema" and describes the "datastore schema" of <operational> as being the
> superset of the datastore schema for all the configuration datastores.
> 
> There are two remaining issues open on the issue tracker
> (https://github.com/netmod-wg/datastore-dt/issues):
> 
> (1) Sign off that usage of RFC 2119 language is appropriate. Perhaps one of
> the proponents of this change could please verify this.
> (2) The email thread regarding Actions and RPCs in NMDA.  I will send
> updated proposed text on the appropriate thread.
> 
> Thanks,
> Rob
> 
> 
> On 30/10/2017 18:04, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Network Modeling WG of the IETF.
> >
> >          Title           : Network Management Datastore Architecture
> >          Authors         : Martin Bjorklund
> >                            Juergen Schoenwaelder
> >                            Phil Shafer
> >                            Kent Watsen
> >                            Robert Wilton
> > 	Filename        : draft-ietf-netmod-revised-datastores-06.txt
> > 	Pages           : 38
> > 	Date            : 2017-10-30
> >
> > Abstract:
> >     Datastores are a fundamental concept binding the data models written
> >     in the YANG data modeling language to network management protocols
> >     such as NETCONF and RESTCONF.  This document defines an architectural
> >     framework for datastores based on the experience gained with the
> >     initial simpler model, addressing requirements that were not well
> >     supported in the initial model.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-06
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datast
> > ores-06
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores
> > -06
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > netmod mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Thu, 2 Nov 2017 17:31:27 -0400

"Sterne, Jason (Nokia - CA/Ottawa)" writes:
>The <running> DS needs to have both the template itself in the schema as well as
>whatever nodes are used to hold 'exploded' data.  But what about intended and
>operational ?

For JUNOS, we carry both the raw and expanded views, though nothing
in JUNOS is looking at the raw data outside of the UI code.  But we
carry it, so that scripts can access this information and find the
original "intent" for config.

For example, if my interface template looked like:

interfaces {
    apply-macro so-0/0/0 {
        inet-address 10.3.2.1/30;
        role customer-facing;
    }
}

and then my commit script turned this into traditional JUNOS
config, like:

interfaces {
    so-0/0/0 {
        unit 0 {
            family inet {
                address 10.3.2.1/30;
                filter customer-facing;
             }
             family mpls;
             family iso;
        }
    }
}
protocols {
    bgp {
        group customer-facing {
            peer 10.3.2.2 {
                local-address 10.3.2.1;
                policy customer-facing;
...

And whatever else "customer-facing" means.

Both sets of config will be in <intended> and <operational> so that
when I find an interface that's down, I can look (in <operational>)
at the original apply-macro and see the role of the interface to know
how loud an alarm I should be raising.

Thanks,
 Phil

---

From: Robert Wilton <[email-masked]>
Date: Fri, 3 Nov 2017 09:39:16 +0000

I agree.

I think that a configuration template is just another form of 
configuration, and hence would expect that the template itself appear in 
candidate, startup, running, intended, operational.

There could also be "system templates" that are not directly 
configurable, and do not appear in configuration (e.g. I think that a 
system defined Loopback0 interface could be thought to be part of a 
"system template").  E.g. basically just configuration that the system 
always merges in from running to intended.  Today, I would not expect to 
"see" these system templates, only the affect of them in <intended> and 
<operational>.

Thanks,
Rob