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

From: Randy Presuhn <[email-masked]>
Date: Tue, 7 Apr 2015 14:19:03 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman 
>Sent: Apr 7, 2015 12:01 PM
>To: Randy Presuhn 
>Cc: "[email-masked]" 
>Subject: Re: [netmod] New 6087bis issues - connect config - state -	statistics
>
>Hi,
>
>Maybe it would help if we agreed on the problem that needs to be solved
>rather than dismissing solutions based on our own understanding
>of the priorities.
>
>Using the interfaces model as an example (as done in the
>draft)...
>
>  1) The NETMOD WG decided it was very important to be able
>     to represent interfaces that were not configured. The openconfig
>     solution does not allow this feature.  Only configured interfaces
>     would have an 'operational' subtree. The system discovered
>     interfaces could not be represented.

I think being able to provision interfaces in advance of installation
is important.

I think that withdrawing a line card should not cause its configuration
to disappear.

I think that a line card replacing another "equivalent" card
should have the configuration of the "old" card applied to
it until/unless management says otherwise.

I think its important for everything that is manageable to
be visible (modulo access control) regardless of whether
it is provisioned or discovered, and that should include
both operational and non-operational information, to the
extent that the information is available.

I suspect we're probably in agreement on all of these.

> 2) Let's say I know that the mtu on 'eth0' is not the
>    same as the configured value.  What does that mean?
>    What am I supposed to do about it?
>    I do not agree that merely knowing the operational knob is
>    not the same as the configured knob is enough information
>    to be actionable.

Agreed.  That's why the configuration and operational knobs
in such a situation are, at least to my mind, distinct pieces
of management information with different semantics.  I think
treating them as though they were the "same thing" but in
different data stores is asking for a world of hurt. 

There *is* a relationship; I think folks differ on how (or even
whether) to represent that relationship in the information
model, and the extent to which they believe management applications
could make use of that knowledge.

I think we're agreed that what's been done so far is a bit
klunky at best.

>So please describe the problem in enough detail so we
>can decide if there is agreement on anything.  We aren't drilling
>holes or smashing nails.  Stick to the details of network management
>problems related to operational state.

I think we're actually in violent agreement, though you and I are
describing it in characteristically different ways.  That's
not new.  :-)   My point is that formulating it as a datastore
problem (or as an extension to the corresponding model/protocol
mechanisms) is really just another attempt at using structure
to solve a problem which is just an instance of a class of
problems which are fundamentally independent of models' structures.

Sticking to "operational state" falls apart if one decides to
slice and dice the information at finer levels of granularity,
e.g. performance statistics, security statistics, throughput,
alarm statuses, etc.  If there's just one big bucket of "operational
state", the datastore view is kinda plausible.  If finer, potentially
overlapping subcategorization are needed, the datastore view
quickly becomes a mass of spaghetti.  The question is whether
application developers or users benefit enough from
having that finer level of granularity represented in models
to make it worth the modeling effort.  You know my leanings
on that point, but since I'm not implementing this stuff, I'm
staying officially agnostic.

It's a tough issue because rigorously specifying the semantic
relationships almost certainly means someone's implementation
would have to change in order to conform to the more fully/precisely
specified semantics.  Netconf / Netmod has tried very hard to be
minimally constraining on vendors' implementation, so I think
there's a built-in cultural bias against dealing with these
problems.  It's certainly the group's right to stick with this
approach, but that also means that this class of problems will
continue to accrete ad hoc solutions.  It's conceivable that
that's the right thing to do, even though I instinctually
recoil from it.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Apr 2015 15:13:12 -0700

> problems which are fundamentally independent of models' structures.

Datastores are conceptual API mechanisms.
They may be implemented in the client and server in
different ways, such as 1 data structure representing
all datastores.  They just represent some state in the device.

But I agree that an operational datastore by itself would
not solve the complex mapping problem.  More machine-readable
statements would help, assuming we could agree on the details.

A new operation like <get-related-operational> would
not be limited in returning the same data as named in the config.

   rpc get-related-operational {
      description
        'Retrieve operational data related to the specified configuration data';
      input {
        leaf target {
          mandatory true;
          type instance-identifier;
        }
      }
     output {
        anyxml data {
          description
            'Represents a container with subtrees of operational data';
        }
     }
 }

An approach like this would punt the complexity to the server, but
it does not require the YANG data modeler to be aware of all relevant
operational state for all implementations. (An unsolvable problem).

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Apr 2015 09:28:43 +0200 (CEST)

> I suspect we're probably in agreement on all of these.

Agreed.

> different data stores is asking for a world of hurt. 

I certainly agree, and this is why we ended up with the model we have
in ietf-interfaces.

Note that when I suggested to use a separate datastore, it was in
order to solve *one specific* problem described in
draft-openconfig-netmod-opstate-00.  But it might be that I have
misunderstood the problem description.  They talk about "intended
configuration" and "running configuration":

   o  Where the application of a change is asynchronous - due to system
      operations, or a pre-requisite for another event to occur before
      the configuration value is applied (e.g., a protocol session
      restart) - then the intended configuration value may not determine
      whether the configuration has been committed to the running
      configuration; or whether the pre-requisite event has occurred.

They also talk about asynchronous changes being a property of the
implementation, rather than the modelled data (see section 2).  And
this is probably where there is some confusion.

So instead of speculating further, could someone explain if sync/async
is supposed to be a property of the implementation (in which case I
beleive a separate datastore could be solution) or of the data (like
in ietf-interfaces (where a separate datastore does not work)).

> model

Right.  So draft-openconfig-netmod-opstate-00 proposes that this
relationship is defined by the data structure using naming
conventions.  Andy showed an alternative with an explicit statement.

> and the extent to which they believe management applications

Yes, this is not entirely clear to me.  I can certainly see how a
human user could ask for "all related info" and process that data.
But it is not clear how a program (nms/orchestrator/controller/...)
can use this information, without knowing what it is looking for.

/martin

---

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

> that's the right thing to do, even though I instinctually

I think one aspect we have to keep in mind is that it is hard to
control how people write YANG models. Not all module writers will have
the same level of time and sophistication. And there will be several
organizations involved in writing models, not just the IETF. So facing
reality, we have to accept that YANG module structures will never be
perfect. Even if we agree on some structural rules for the IETF and we
find lots of volunteers to review all data models for compliance to
these rules (I see a big problem here), we will fail for modules done
outside the IETF.

I think this can be compared to APIs of many open source C libraries.
Would it not be nice if they were all following similar conventions?
Well, the reality is that they don't and hence there is a learning
curve which each of them. (But there is also some good aspect of this,
people are free to try out other hopefully better ideas.)  I think the
key here is accepting the reality of a fully distributed and loosely
controlled YANG data model development process.

If YANG becomes successful and widely used, I believe we will need at
some time something like Andy's conformance packages or other data
model annotations that provide additional meta-data to further
automate processing and that can cut through data models in several
different meaningful aspects. I agree with Randy that trying to encode
all of these cross-cutting aspects into data model structure is not
really workable.

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