Subject: [netmod] draft-openconfig-netmod-opstate: Changes in -01

From: Rob Shakir <[email-masked]>
Date: Fri, 07 Aug 2015 09:59:55 -0400

Hi netmod folks,

Prior to the Prague IETF, Anees, Marcus and I took some time to update 
draft-openconfig-netmod-opstate. The intent of this update was two-fold:

  * to provide clarifications of the types of data that we consider to
    exist within a YANG module. This very much reflects the discussions
    that we had both on the interim meeting calls, and subsequently on
    the list. We aimed to document the terms 'intended configuration',
    'applied configuration' and 'derived state', and record the
    relationship between them that we'd iterated on.
      o This is contained in Section 2. We would encourage interested
        parties to review these definitions to ensure that the common
        understanding that we reached has been documented.

  * add some clarifications to the requirements based on alternative
    suggestions that had been briefly mentioned during the interims.
    Particularly, it is worth mentioning:
      o Section 4.5: we added some clarification about paths within some
        of the NMS systems that we are working on.
      o Section 7: which is dedicated to covering some of the
        observations that have been made relating to the proposed
        solution. We (the authors) have tried to provide some feedback
        to some of these points (where it has been possible to do so).

The diff for this revision can be found at 
https://tools.ietf.org/rfcdiff?url2=draft-openconfig-netmod-opstate-01.txt 
- Appendix D provides a brief changelog.

Kind regards,
r.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2015 16:14:39 +0200

> draft-openconfig-netmod-opstate. The intent of this update was two-fold:

[...]

> - Appendix D provides a brief changelog.

   [...] That is,
   it avoids the need for an NMS to provide a <RPC-call, path> tuple to
   uniquely identify a data node.

I assume you mean <datastore, path> instead of <RPC-call, path>.

/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: Rob Shakir <[email-masked]>
Date: Fri, 07 Aug 2015 10:40:06 -0400

Juergen Schoenwaelder wrote:
> I assume you mean<datastore, path>  instead of<RPC-call, path>.
>
> /js
Hi Juergen,

Generically, the intent here is express that it is '<some-access-method, 
path>' rather than merely 'path'. The 'some-access-method' might be a 
reference to a particular datastore, or a certain operation within the 
access protocol (GET vs. GET-OPER maybe).

Thanks,
r.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2015 17:39:09 +0200

> access protocol (GET vs. GET-OPER maybe).

Configuration data resides in configuration datastores. This is quite
deeply wired in the NETCONF and YANG specifications.

For operations on the configuration datastores, the datastore name is
passed as an argument in RPC calls. Hence, for configuration data, the
naming model is <datastore, path>.

There have been many discussions over the years whether there should
be an explicitly named operational datastore since architecturally we
treat operational data somewhat differently. Some of this is hinted
at in section 4.3.3 of RFC 6244 and you can find also various I-Ds
that were posted in this context.

But you are right, it is not just the path that is needed to identify
data residing in configuration datastores. It is in general a tuple
<selector, path> and for configuration data the selector is a
configuration datastore name.

/js

---

From: Rob Shakir <[email-masked]>
Date: Fri, 07 Aug 2015 15:21:48 -0400

> configuration datastore name.

Thanks for the clarification. Do you have examples of other (i.e., 
non-NETCONF) systems that utilise this convention that a path is not an 
absolute reference to a certain data node? Reviewing with various 
interested parties, I'm not sure that there are clear cases that form a 
precedent for this.

If we consider that this then might drive some new behaviour where the 
systems architecture for NMS differs from elsewhere then we might want 
to question whether this is necessary complexity. Indeed, for me this 
comes back to one of the discussions about the other datastores that we 
had on an interim call.

  * 'startup' is really a property of the intended configuration - as to 
whether it has been made persistent. In general, I see very few changes 
that are made where we interact only with the persistent version of the 
intended configuration; and even fewer where the intended configuration 
is not made persistent. In both cases, it tends to be the lack of a 
declarative configuration API that drives the need to interact with either.

  * 'candidate' is again a property of the intended configuration - 
insofar that the 'candidate' set of configuration represents a set of 
changes that have not been requested to be transitioned to the 'applied 
configuration'. This makes sense when a human is working through 
building up a transaction (configure protocol X, protocol Y .. protocol 
Z, then commit) - but isn't quite so clear when it programmatic 
interaction with the network.

It is quite trivial for me to see cases where an external NMS would 
never really need to interact with either of these datastores - such 
that it's quite tricky for me to determine that we really want to 
architect the entire NMS to be able to carry the <selector,path> tuple 
(stealing your terms, thanks!), especially if this means that it has to 
work entirely differently w.r.t paths than the rest of OSS.

r.

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 09 Aug 2015 22:13:34 +0200 (CEST)

Hi,

Rob Shakir <[email-masked]> wrote:
> non-NETCONF) systems that utilise this convention that a path is not
> an absolute reference to a certain data node? Reviewing with various
> interested parties, I'm not sure that there are clear cases that form
> a precedent for this.

One example is SNMP, where a tuple (enginge id, context, OID) is
needed.  In general you also need a device id of some sort (address,
port).

How the necessary info is handled seems to be an implementation
detail, and it seems to be pretty trivial, but maybe I have
misunderstood something.

> comes back to one of the discussions about the other datastores that
> we had on an interim call.
> 
>    whether it has been made persistent. In general, I see very few
>    changes that are made where we interact only with the persistent
>    version of the intended configuration; and even fewer where the
>    intended configuration is not made persistent. In both cases, it tends
>    to be the lack of a declarative configuration API that drives the need
>    to interact with either.

I do not understand this comment.  Are you proposing some kind of
changes to current YANG models to handle 'startup'?  Are you proposing
changing NETCONF?

>    changes that have not been requested to be transitioned to the
>    'applied configuration'. This makes sense when a human is working
>    through building up a transaction (configure protocol X, protocol Y
>    .. protocol Z, then commit) - but isn't quite so clear when it
>    programmatic interaction with the network.

If I understand your terms correctly, 'running' would be the intended
configuration.  'candidate' is a separate structure, that is not part
of the intended configuration.

Are you proposing some YANG or NETCONF changes to handle the candidate?

> (stealing your terms, thanks!), especially if this means that it has
> to work entirely differently w.r.t paths than the rest of OSS.

Even if we had the four separate datastores 'startup', 'running',
'candidate', and 'applied', it is not entirely clear to me why the
datastore would have to be carried together with the path internally
all the time.  (We do not carry the current datastores in our system
today).  Maybe this is an implementation issue?

/martin

---

From: Rob Shakir <[email-masked]>
Date: Sun, 09 Aug 2015 16:29:03 -0400

Martin,

To be clear -- I'm not proposing any changes to YANG or NETCONF. I was 
merely trying to write down the discussion that we had on one of the 
interims about ways that 'datastores' may be considered by some 
implementations, particularly as this view can mean that they might be 
able to ignore them - based on the current ones that are implemented.

> today).   Maybe this is an implementation issue?
Sure, it does not have to be carried all the time, but is /is/ required 
in some cases. If one wants a standardised 'path' format to be passed 
between systems then there's going to need to be space for the 
'datastore' to be carried in path references that are handed about (even 
if there is a 'default' datastore). I, for one, would find it messy if 
there needs to be context specific ways of handling what a path looks like.

I find the fact that there can be ambiguity for a certain path something 
that is quite different from all other systems, and hence consider it to 
be suboptimal when compared to having a unique path to a particular set 
of data. Having a path that can result in different values being 
returned seems fragile.

Best,
r.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Aug 2015 09:12:48 +0200

> interested parties, I'm not sure that there are clear cases that form a 

SNMP has an even more complex naming scheme.

> declarative configuration API that drives the need to interact with either.

You can have a NETCONF server without 'startup' and it still has
persistent running config. I have no clue what 'the lack of a
declarative configuration API' means.

> interaction with the network.

There are commercial implementations that make use of candidate
datastores and the transaction, validation and rollback capabilities
they provide. You may decide that you do not need them but this does
not imply that nobody else will need them.

> work entirely differently w.r.t paths than the rest of OSS.

It is certainly up to you how you architect your NMS the way to think
it works best. I am just trying to explain how NETCONF and YANG
work. But I would expect that an NMS is able to integrate namespaces.

The <selector, path> approach allows us to use the same path in
different datastores, this is considered to be a feature and not a
bug.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Aug 2015 15:35:04 -0700

> declarative configuration API' means.

The startup datastore simply represents the config that will be used
at the next reboot.

It is useful to compare the running config to candidate or startup.

> not imply that nobody else will need them.

RFC 6241 should be clear that the candidate is a scratchpad.
It has no effect on the system unless and until a <commit> is attempted.
Since NETCONF (incorrectly) couples the confirmed commit procedure
with the candidate config, it is useful to programmatic APIs.
In reality, confirmed commit has absolutely nothing to do with
candidate, but there seems to be no interest in fixing that.

> work. But I would expect that an NMS is able to integrate namespaces.
We should not dumb-down the standard to support dumb NMS software.
Datastores and namespaces are part of the standard.  Neither are
difficult to implement.

> different datastores, this is considered to be a feature and not a

Andy

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