Subject: Re: [netmod] NetConf Operational Model Question

From: "Patrick Gili (pgili)" <[email-masked]>
Date: Wed, 30 Jul 2014 12:31:36 +0000

Clyde,

This doesn¹t make sense.  Read section 5.1 of RFC 6241 to better
understand why I think so.

-Patrick

On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" <[email-masked]> wrote:

>Hi,
>
>Some operational data reflects data in the running config. Examples from
>IETF models:
>- the IETF routing model duplicates most leafs but not all -
>routing-instance, rib-name, rib address-family, rib recipient-ribs,
>route-filter.
>- the ietf-interfaces model duplicates some leafs but not all - name,
>type.
>
>Under what conditions is it acceptable or desirable to model data that is
>available as part of the running config as operational data?
>
>Looking at the existing models I could not see a pattern.
>
>Thanks,
>
>Clyde
>
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2014 07:08:09 -0700

> understand why I think so.
The running configuration contains only the config=true subset of all
YANG data nodes.

IMO, the only reason to replicate the configuration structure
(non-terminals, keys)
in operational state (like ietf-interfaces) is because the state can exist
independently
of the configuration.  Most of the time, this is a bad idea and doesn't
really make sense.

  - Can the data structure being modeled exist on its own as state without
any config?
    If yes then dual data structures are needed.

  - e.g., What does it mean if an interface is reported as state but does
not
    exist in the configuration?  (I sure don't know)

  - How many of the leafs (properties) of the configured data structure can
    be changed by means other than configuration edits? If none or very few,
    then duplicating the data as config and state is not needed.

 - Does the operator need to know the operational state values that are
overriding
   specific configured values? What breaks if the operator thinks the
configured
   value is in use but it is a different value?

-Patrick

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jul 2014 18:28:54 +0200

On 30 Jul 2014, at 16:08, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) <[email-masked]> wrote:
> Clyde,
> 
> IMO, the only reason to replicate the configuration structure (non-terminals, keys)
> in operational state (like ietf-interfaces) is because the state can exist independently
> of the configuration.  Most of the time, this is a bad idea and doesn't really make sense.

I don’t agree. This is what I read in sec. 3 of RFC 3535:

   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.

   3.  It is required to be able to fetch separately configuration data,
       operational state data, and statistics from devices, and to be
       able to compare these between devices.

See also sec. 3 in

http://tools.ietf.org/html/draft-tp-i2rs-yang-00

> 
>   - Can the data structure being modeled exist on its own as state without any config?
>   - e.g., What does it mean if an interface is reported as state but does not

If you boot a Linux box, interfaces like “eth0” appear before you get a chance to configure anything (we call it system-controlled interfaces)

>     then duplicating the data as config and state is not needed.

Pretty much everything on systems that aren’t stricty NETCONF-centric. A generic operating system doesn’t give a damn about NETCONF. 

> 
>  - Does the operator need to know the operational state values that are overriding
>    specific configured values? What breaks if the operator thinks the configured

For example, it is usually useful to know the IP address the system is really using on an interface.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2014 09:41:24 -0700

On Wed, Jul 30, 2014 at 9:28 AM, Ladislav Lhotka <[email-masked]> wrote:

> I don't agree. This is what I read in sec. 3 of RFC 3535:
>
That's why we have a separate <get-config> operation.
It makes it very easy to prune out all the state data.

The tree abstraction is just an API. The XML is just a representation.
A server implementation is free to organize data any way it wants.

YANG supports many ways to organize data any way that seems right
for a particular data model.  IMO it is a waste of time to force one
way or another.  Perhaps the YANG Patterns draft will make the
design choices easier to understand.

>        able to compare these between devices.

So? We have <get-config>.
Anybody can write an RPC that retrieves only state (see <get2> in
NETCONF-EX).

Any offline tool can also separate data for comparison, based on the
value of the config-stmt.

> If you boot a Linux box, interfaces like "eth0" appear before you get a
> chance to configure anything (we call it system-controlled interfaces)
>

So an implementation would populate on interface-state, and nothing
in interface? So an admin (or even root) can never
change anything on 'eth0'?  So is there is an entry
for 'eth0' in the interface list?

> Pretty much everything on systems that aren't stricty NETCONF-centric. A
> generic operating system doesn't give a damn about NETCONF

huh?  Servers are implemented so that any protocol that changes config are
supposed to reflect the config changes in NETCONF.

It cost memory to duplicate trees for no good reason.
These are design choices the YANG model authos need to
consider.  YANG doesn't care which design you use.

> .

I am just trying to provide some questions designers should consider
instead of blindly
copying one module or another.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jul 2014 19:56:48 +0200

> A server implementation is free to organize data any way it wants.

It is not about data organization but rather about the ability "to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols.”

> Anybody can write an RPC that retrieves only state (see <get2> in NETCONF-EX).

Not if state data are buried inside configuration and a particular instance has no configuration (yet). 

> for 'eth0' in the interface list?

Please read about system-controlled interfaces in RFC 7223.

> Pretty much everything on systems that aren’t stricty NETCONF-centric. A generic operating system doesn’t give a damn about NETCONF
> 
> 

Which servers? Do you think “ifconfig" or “ip” behave this way? What if something changes in operational state and the config datastore is locked?

Lada

> I am just trying to provide some questions designers should consider instead of blindly

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2014 11:17:22 -0700

On Wed, Jul 30, 2014 at 10:56 AM, Ladislav Lhotka <[email-masked]> wrote:

> It is not about data organization but rather about the ability "to
> determine which parameters were administratively configured and which were
> obtained via other mechanisms such as routing protocols."
>

You can do that with YANG.
Separate the config and non-config in different modules if you want.
What is your point? Every data model will have different requirements
and design considerations.  You pointed out a couple that you prefer to
keep as separate trees.  That doesn't mean every YANG model
will need to do that.  E.g. -- If I want to maintain counters associated
with some config (ACL rule hits, RMON host table counters)
then adding config=false under the config for some collection works great.

> instance has no configuration (yet).

Yes, we already went over this -- if the state can exist independent of the
config
then it cannot be under the config. Then the YANG designer will not do that
because this data model needs separate config and state.

Andy

> Please read about system-controlled interfaces in RFC 7223.

I did. Just because 1 module is designed this way doesn't mean
every module should be the same.  You want to have some magic state
that is editable by the client, and comes back after a reboot?
I prefer to think of it as server-created config. Our server supports
this sort of write limitation on a config=true node.

> Which servers? Do you think "ifconfig" or "ip" behave this way? What if
> something changes in operational state and the config datastore is locked?
>

If somebody writes a NETCONF server they are responsible to make it work
correctly.
Not the IETF's problem to design an open API on Linux to support NETCONF.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2014 07:05:05 +0200

On Wed, Jul 30, 2014 at 11:17:22AM -0700, Andy Bierman wrote:

> [...] If I want to maintain counters associated with some config
> (ACL rule hits, RMON host table counters) then adding config=false
> under the config for some collection works great.

Are the counters associated with the configuration or with the
function that was configured? I think the later is the way I look at
things. The question then becomes whether the function can exist
without explicit configuration.

For ACLs, you might say this is true. However, if I look at things
like the Port Control Protocol (PCP), I am not sure anymore this
assumption is generally true. Operationally it would be kind of odd to
be able to get counters for configured ACL rules but not for
dynamically injected ACL rules created by PCP and the like.

The number of situations in which a function can only exist with
explicit configuration may actually be rather small since there is a
tendency to start with explicit configuration for new network
functions and over time to complement things with specific control
protocols.

/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: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jul 2014 07:27:11 +0200

> will need to do that.  E.g. -- If I want to maintain counters

Of course, but you wrote "Most of the time, [duplicate config and state
trees] is a bad idea and doesn't really make sense. I just disagree
with this statement.

> because this data model needs separate config and state.

IMO, state data inside configuration is a dubious practice violating the
items 2 and 3 that I cited from RFC 3535.

> that is editable by the client, and comes back after a reboot?

No magic involved, what comes up after reboot as operational state just
reflects hardware configuration.

> If somebody writes a NETCONF server they are responsible to make it work

The server behaviour you describe is just wishful thinking with no
support in RFC 6241. I'd rather think about (NETCONF) configuration as
something being completely under control of NETCONF client(s), and it's
not the server's business to tinker with it.

Lada