Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics

From: Randy Presuhn <[email-masked]>
Date: Fri, 3 Apr 2015 11:43:42 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Apr 3, 2015 2:14 AM
...
>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics
...
>RESTCONF already has the 'content' query parameter that allows
>config, operational, or both.  This is good enough.
>It is trivial for you to add your own content filters to
>the RPC operations (if you want to prove that standards
>for more classifications are needed)

I think you're setting a really low bar for "good enough,"
but recognize that this is a judgement call.

As the number of aspects of interest grows, it becomes more
important that the models should have information allowing
their bits and pieces to be marked in some way so that
aspect-oriented operations become practical.  I'm not
suggesting that the route of the GDMO "PACKAGE" construct
is necessarily the way to go, but the need to be able to
factor definitions in this way has been recognized, if
not necessarily exploited, since at least the 1980's.

Getting back to the start of this thread, there's an underlying
question of whether there should be some set of standardized
aspects, e.g. "statistics" or "performance", built into the
modeling environment (as config and operational, for example)
or whether the modeling language should provide a facility for
identifying new aspects, some of which might potentially
eventually be enshrined in standards-track specifications.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2015 12:07:54 -0700

> but recognize that this is a judgement call.

I really don't want YANG Doctors in long debates whether
a particular leaf is operational state, a performance counter,
a fault counter, or some combination of everything.

I agree the complete lack of a classification system makes it
difficult to construct a high-level view of multiple YANG modules,
but this is something that vendors and SDOs may figure out over time.

We could add statements like "related-to /some/path;" then
we could have a different sub-statement for each type of relation.

   container interfaces {
      related-to /if:interfaces-state { ... }
      ...
    }

I don't know that this will be any better than description-stmts.
It would certainly be a lot of effort to add new statements.

> eventually be enshrined in standards-track specifications.

I had classification statements in the YANG conformance draft but was
told to take them out because we did not need to add any meta-data
to modules (objects or conformance) that gave some classification
related to FCAPS.  We did not need any functional classifications
like 'routing, access-control, logging'.

> Randy

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2015 15:08:02 -0700

> eventually be enshrined in standards-track specifications.

How are client tools expected to use the extra classifications?
Do we expect operators and programmers to pick out
the interesting child nodes for a given list or container,
or do we expect applications to automatically select based
on this extra classification?

Do we expect ETags for separate types of operational state to
be maintained?  Caching data, pushing data, retrieval filters
all need to be designed together to be efficient and useful.

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2015 19:55:05 -0700

> but recognize that this is a judgement call.

There have been proposals to the NETCONF WG
several times to address the operational state issue
in the NETCONF protocol.

There was the <get2> operation in NETCONF-EX that
added many new retrieval options.
Martin proposed a <get-operational> RPC that could
solve this problem. Phil suggested a new operational
datastore at the IETF meeting instead of replicating datastore
contents.

Do you have a definition of "statistics" that everyone will
understand so we can add some new YANG statement
to pick between different kinds of config=false nodes?

Andy

---

From: Anees Shaikh <[email-masked]>
Date: Mon, 6 Apr 2015 01:58:04 -0700

The suggestions in Martin's earlier draft actually don't address all of the
requirements, and are closely tied to NETCONF datastore semantics (it was
also not pursued).  Mapping to something like RESTCONF, for example, would
either require new request headers or new URL constructs, the latter not
being much different than our proposal.  We spent a good deal of time
working through use cases that leverage datastores but dismissed it at the
end.  That said. we can think through this again with others.

Regarding the definition of statistics, there is some discussion in the
draft -- we consider three types of state data: i) statistics / counters,
ii) element- or protocol-generated state (e.g., #prefixes received on a BGP
session), iii) current, actual configuration (that may differ from intended
configuration).

We also proposed an additional tag (operational: true) that would mark only
(i) and (ii) so that synchronous systems would not have to retrieve
redundant data on a <get> call.  This could be generalized further if one
cares about also distinguishing (i) and (ii).

thanks.
-- Anees

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 09:11:40 +0200

> session), iii) current, actual configuration (that may differ from intended

The problem is that all of this is not clear cut. If I receive an IP
address via DHCP, is that not element- or protocol-generated state?  I
guess you assume it is current, actual configuration - but what makes
something current, actual configuration and what makes it element- or
protocol-generated state? Why are #prefixes received on a BGP session
not statistics - sounds like counter/gauge to me.

While we can discuss these particular examples, I do wonder if even
the examples used to promote the idea really work easily. RFC 3535
says this:

   2.  It is necessary to make a clear distinction between configuration
       data, data that describes operational state and statistics.  Some
       devices make it very hard to determine which parameters were
       administratively configured and which were obtained via other
       mechanisms such as routing protocols.

This is have we have been working with since then. It remains unclear
why we now should move to a system distinguishing 4 different kinds of
data instead of the 3 we talk about since the IAB workshop.

/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/>