Subject: [netmod] Questions on NMDA and "merged config and state"

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 3 Aug 2017 06:59:58 +0000

Hi,

Just to get confirmation on my assumptions:

In section 4.7.3 the origin metadata does not include 'running' as origin
but only 'intended'.  So it seems to be mandatory for a NC server to support
the intended datastore?

With the introduction of the operational datastore I assume it also means
that when someone wants to know what the client has configured on the device
a get-config on the running datastore is required while to know the 'in-use'
configuration a get(-config) on the operational datastore is required?

The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines
mentions that a derived module can be generated from the YANG models where
state and config are merged in a single branch.  In the simple example this
results in another YANG model with its own namespace.  I assume that this
state YANG model will then also show up in the hello message?

Best regards,

Bart

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Aug 2017 09:49:25 +0200

> but only 'intended'.  So it seems to be mandatory for a NC server to support

If your server does not support templates or inactive configuration or
the like, then intended is just an alias for running. I do not think
you need to expose intended in this case. Still, the value of the
origin attribute is 'intended' since in the general case, the
configuration is coming from <intended>.  
 
> configuration a get(-config) on the operational datastore is required?

Yes. The operation, however, is likely called get-data in NETCONF, at
least this is what draft-dsdt-nmda-netconf-00 suggested.

> state YANG model will then also show up in the hello message?

The general idea is that we produce YANG modules that have config and
state merged into a single branch. Out of this YANG module, people may
generate a separate module that consists of the config false nodes
plus any additional key nodes needed to make it work. Such a YANG
module will be treated as any other YANG module. Note that YANG 1.1
started to move module announcements to the ietf-yang-library to avoid
very long module announcements during session startup.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Aug 2017 09:18:10 -0700

On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> the like, then intended is just an alias for running.

IMO this is not correct.
There are no standards at all to define these things.
Our server supports an implementation of config templates that expands the
template when it is first created.  A different proprietary implementation
MAY choose
to expand templates in some other way.  Since there are no standards for
this purpose,
any proprietary implementation decision is valid.

The contents of the "intended" datastore are purely proprietary.
The opaque nature of this datastore is by design and the WG accepts that
servers
are free to choose to implement whatever datastores they want.
The origin metadata should just reflect what the server does, not mandate
any sort of datastore conformance.

Andy

> I do not think
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Aug 2017 18:32:34 +0200

> any proprietary implementation decision is valid.

So your implementation allows a client to write something to <running>
that transforms into something different at the time it is written (or
committed I assume)? Anyway, my statement was:

So it does not apply to your implementation.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Aug 2017 09:49:25 -0700

> So it does not apply to your implementation.

IMO the concept of NMDA conformance is still very under-specified.
There should be a clear statement in RFC 2119 terms for the exact
datastores that are considered standard datastores.  This needs to be 100%
backward
compatible with RFC 7950 and RFC 6241 requirements for the 3 traditional
datastores.
I don't care if new datastore usage is unbounded, as long as the client
developer
knows what to expect from an NMDA-compliant server.

The WG needs to deliberately (not haphazardly) determine the
interoperability boundaries.

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Aug 2017 18:53:48 +0200

> IMO the concept of NMDA conformance is still very under-specified.

Seems you are changing topic.

> datastores that are considered standard datastores.  This needs to
> be 100% backward compatible with RFC 7950 and RFC 6241 requirements
> for the 3 traditional datastores.

The protocols (with their various capabilities) expose different sets
of datastores. I agree, the protocol documents should state clearly
what is required to expose for the different protocols and what is
optional to expose.

> I don't care if new datastore usage is unbounded, as long as the
> client developer knows what to expect from an NMDA-compliant server.
> 

Yes, but it is not this WG but the other WG I think.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Aug 2017 10:06:23 -0700

On Thu, Aug 3, 2017 at 9:53 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > > > > In section 4.7.3 the origin metadata does not include 'running'
> as
> > > origin
> > > > > > but only 'intended'.  So it seems to be mandatory for a NC
> server to
> > > > > support
> > > > > > the intended datastore?
> > > > >
> > > > Our server supports an implementation of config templates that
> expands
> > > the

So you are saying there is no such thing as an NMDA-compliant server.
There are protocols that may use specific datastores in various ways.
Different protocols can have different behavior for the same datastore.
Sounds very fun for client developers to figure out.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Aug 2017 08:29:03 +0200

> Sounds very fun for client developers to figure out.

This is what I wrote:

I did not write that different protocols can have different behavior
for the same datastore. I did not write that protocols may use
specific datastores in various ways.

/js

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 4 Aug 2017 06:39:21 +0000

On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder 
<[email-masked] 
<mailto:[email-masked]> > wrote:

On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) 

IMO this is not correct.

template when it is first created.  A different proprietary implementation MAY 
choose

to expand templates in some other way.  Since there are no standards for this 
purpose,

[Bart Bogaert] In that case I would expect that the running is also included 
as an origin of the data in the operational datastore?

Regards, Bart

Andy

I do not think

/js

_______________________________________________
netmod mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 4 Aug 2017 07:03:43 +0000

Maybe a stupid question from my side (I'm not involved  in the NMDA work)
but is there some kind of consensus on what is proposed in this draft RFC or
are we miles away from such a consensus?  Since this is linked to how a
server has to handle state in the proposed merging of config and state under
one branch of the tree coming to a conclusion to me seems a requirement
since in the current implementation we just can't change a CT leaf in the
running DS by a value that is dynamically learned; in the NMDA approach that
would be possible as the operational DS contains both CT and CF leaves and
consequently a value as configured by the client can be overwritten by a
dynamically learned value as the value configured by the client remains
untouched in the running DS.  In the current implementation we would need to
model a CF leaf for this purpose.  At least that is how I have always
understood how it should be done.  As long as we do not have NDMA-based
server implementations we can't design and implement YANG models as proposed
in NMDA and its associated guidelines.

Regards, Bart

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, August 04, 2017 8:29 AM
To: Andy Bierman <[email-masked]>
Cc: Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>;
[email-masked]
Subject: Re: [netmod] Questions on NMDA and "merged config and state"

This is what I wrote:

I did not write that different protocols can have different behavior for the
same datastore. I did not write that protocols may use specific datastores
in various ways.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 4 Aug 2017 08:56:11 -0700

> specific datastores in various ways.

So the protocol designers will some how agree on the properties of a
standard datastore?
Actually it seems much worse than that. It seems each server implementation
decides what it wants to support and just lists that.

The 7895bis draft proposes that each server will list the properties it
supports for each datastore

        container properties {
           leaf-list property {
             type identityref {
               base ds:property;
             }
             description
               "A property of the datastore.";
           }
           description
             "A list of properties supported by this datastore.";
         }

Of course, these properties are just a list of identityrefs that match the
base 'ds:property'.
There is no official list of properties that a datastore is expected to
support.

There is this list in ietf-datastores that seems to be intended to replace
the existing capability URIs for various NETCONF capabilities:
There does not seem to be any guidance or normative text.
NMS developers should take notice of these changes because the
impact on code design could be significant.

     identity property {
       description
        "Abstract base identity for datastore identities.";
     }

     identity writable {
       base property;
       description
         "Used on the 'running' datastore to indicate that it can be
          written to."

     }

     identity auto-persist {
       base property;
       description
         "Used on the 'running' datastore to indicate that writes to
          it will be automatically persisted.

          If the 'startup' datastore is also supported, clients may
          query its contents to ensure its synchronization.

          If the 'startup' datastore is not supported, and this
          property is not set, then clients must use a mechanism
          provided by the protocol to explicitly persist the
          'running' datastore's contents.";
     }

     identity rollback-on-error {
       base property;
       description
         "Used on either the 'running' or 'candidate' datastores to
          indicate that clients may request atomic update behavior.";
     }

     identity confirmed-commit {
       base property;
       description
         "Used on the 'candidate' datastore to indicate that
          clients may request confirmed-commit update behavior.";
     }

     identity validate {
       base property;
       description
         "Used on the 'candidate' datastore to indicate that
          clients may request datastore validation.";
     }

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 5 Aug 2017 10:36:10 +0200

> in NMDA and its associated guidelines.

Bart,

you may want to look at draft-dsdt-nmda-guidelines-01. Protocol updates
to support NMDA are on the way as well, draft-dsdt-nmda-netconf-00 and
draft-dsdt-netconf-restconf-nmda-00.

/js

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sun, 6 Aug 2017 07:57:47 +0000

Hello Juergen,

I have also noticed this but when I look at the type of remarks Andy is
making I get an impression that "dust has not settled" on how this will work
in "real life".

Regards, Bart
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Saturday, August 05, 2017 10:36 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>
Cc: Andy Bierman <[email-masked]>; [email-masked]
Subject: Re: [netmod] Questions on NMDA and "merged config and state"

On Fri, Aug 04, 2017 at 07:03:43AM +0000, Bogaert, Bart (Nokia - BE/Antwerp)
wrote:
> Maybe a stupid question from my side (I'm not involved  in the NMDA 
> work) but is there some kind of consensus on what is proposed in this 
> draft RFC or are we miles away from such a consensus?  Since this is 
> linked to how a server has to handle state in the proposed merging of 
> config and state under one branch of the tree coming to a conclusion 
> to me seems a requirement since in the current implementation we just 
> can't change a CT leaf in the running DS by a value that is 
> dynamically learned; in the NMDA approach that would be possible as 
> the operational DS contains both CT and CF leaves and consequently a 
> value as configured by the client can be overwritten by a dynamically 
> learned value as the value configured by the client remains untouched 
> in the running DS.  In the current implementation we would need to 
> understood how it should be done.  As long as we do not have 
> NDMA-based server implementations we can't design and implement YANG
models as proposed in NMDA and its associated guidelines.

Bart,

you may want to look at draft-dsdt-nmda-guidelines-01. Protocol updates to
support NMDA are on the way as well, draft-dsdt-nmda-netconf-00 and
draft-dsdt-netconf-restconf-nmda-00.

/js