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

From: Randy Presuhn <[email-masked]>
Date: Tue, 7 Apr 2015 11:29:44 -0700 (GMT-07:00)

Hi -

I find this thread frustrating because it seems to me like
a conversation about selecting the appropriate hammer for
drilling a hole.

To me, having a selection of datastores is just an elaboration
on the tool of *structure* as though it were the sole
organizing principle for management information.  Perhaps
this is a natural consequence of an XML-centric approach.

Until/unless the Yang metamodel provides some mechanism for
representing semantic commonalities beyond structural
replication, ad hoc naming conventions, and cryptic natural
language commentary, I think this discussion will continue
to make it look as though the group's priorities were:
  1) convenience of Yang language definers
  2) enabling tool implementors to throw something together
     as quickly as possible
  3) impose as few constraints on modelers as possible
  4) hope that application developers can make it do something
     useful
  5) let the users be grateful for whatever crumbs of information
     they can get.

I know (or at least hope) that's not the group's intent.

Perhaps I'm being unfair, but there seems to be a gaping
chasm between the visions expressed at the IESG workshop
oh-so-long-ago and what's on the table today.

Randy

---

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

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.

 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.

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.

 Andy

On Tue, Apr 7, 2015 at 11:29 AM, Randy Presuhn
<[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Rob Shakir <[email-masked]>
Date: Tue, 7 Apr 2015 20:28:53 +0100

> interfaces could not be represented.

I don’t think this is true. Why can an interface not have interface[name=some-interface]/config/X (which has a corresponding interface[name=some-interface]/state/X) and interface[name=some-interface]/state/installed = false ?

The ‘state’ container does not exist underneath the config container in draft-openconfig-netmod-opstate-00.

r.

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 7 Apr 2015 20:24:58 +0000

Hello,
Balazs has two use cases to solve:
1) I get an alarm about some managed object. Let's assume an instance identifier points out the object. I want to be able to see both its configuration and state data (all) belonging to that object to find out what is going on
2) I am collecting counters about an object. When the counters show strange values, I want to see the configuration and state (e.g. operationalState) data for that object
Regards Balazs

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, 07 April, 2015 21:02
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)...

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.

 Andy

On Tue, Apr 7, 2015 at 11:29 AM, Randy Presuhn <[email-masked]> wrote:
> Hi -
>
> I find this thread frustrating because it seems to me like a 
> conversation about selecting the appropriate hammer for drilling a 
> hole.
>
> To me, having a selection of datastores is just an elaboration on the 
> tool of *structure* as though it were the sole organizing principle 
> for management information.  Perhaps this is a natural consequence of 
> an XML-centric approach.
>
> representing semantic commonalities beyond structural replication, ad 
> hoc naming conventions, and cryptic natural language commentary, I 
> think this discussion will continue to make it look as though the 
> group's priorities were:
> Perhaps I'm being unfair, but there seems to be a gaping chasm between 
> the visions expressed at the IESG workshop oh-so-long-ago and what's 
> on the table today.
>
> Randy
>

---

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

> 1) I get an alarm about some managed object. Let's assume an instance identifier points out the object. I want to be able to see both its configuration and state data (all) belonging to that object…

What if the operational state applies to more than 1 config subtree?
Do you want the operational state replicated under each config subtree?

What if the operational state only applies to some of the associated
configuration subtree(s)?  How do you know (besides description-stmt)
which operational subtrees are meaningful at any given moment?

> 2) I am collecting counters about an object. When the counters show strange values, I want to see the configuration and state (e.g. operationalState) data for that object

What if there is not a 1:1 mapping between a config leaf and an
operational leaf.
How does NETCONF or YANG know the difference between a strange counter
value and a normal counter value?

Perhaps new extension statements that describe this complex mapping
would be helpful.  The root of the data (assuming there is only 1 of interest)
is not that hard to map:

    container interfaces {
       oper:operational-path /if:interfaces-state;
       ...
    }

IMO requiring all operational data to be rooted under its associated
config data is too simplistic and not even required.  A "operational-path"
statement works just as well without all the cut-and-paste.

Andy

---

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

> The ‘state’ container does not exist underneath the config container in draft-openconfig-netmod-opstate-00.

  grouping example-structure {
       description
         "top level grouping for the example container -- this is used
         to put the config and state subtrees in the appropriate
         location";

       container example {
         description
           "top-level container for the example data";

         container config {

           uses example-config;

         }

         container state {

           config false;
           uses example-config;
           uses example-state;
         }
       }
     }

OK -- I see you are just adding 'config' and 'state' containers to
everything, and defining the configuration in a grouping so it
can be replicated in the 'state' container.

If we expect the YANG configuration constraints to always apply
to the config=false copy, then this approach is mostly harmless.
The config-stmt is usually enough for an application to tell
which child nodes are config and which are not, so I'm not
sure why we need NP containers called 'config' and 'state' everywhere.

Does this structure get replicated at each level?
In the example-jukebox module in RESTCONF, there is

  container jukebox {
     container library {
        list artist {
          list album {
             list song { ... }
          }
        }
     }
  }

Is there supposed to be config and state containers inserted into the
resource hierarchy at every level?

  container jukebox {
    container config {
      container library {
        container config {
          list artist {
            container config {
              list album {
                container config {
                  list song {
                    container config { ... }
                    container state { ... }
                  }
                }
                container state { }
              }
            }
            container state { ... }
          }
          container state { ... }
        }
        container state { ... }
      }
      container state { ... }
    }
    container state { ... }
  }

Since these containers have no semantics (just names picked by convention),
how does they fit as YANG data resources?

What if there are no operational data nodes related each level of config?
Should there be an empty 'state' containers?

Doesn't the client application need to read and understand the data model
to know the "real" config and operational nodes? If so, then relying on this
these NP containers is for the benefit of applications that do not
know about the YANG data model?

Andy