Subject: Re: [netmod] new issue: configuration versus state data

From: Randy Presuhn <[email-masked]>
Date: Fri, 11 Apr 2014 13:07:34 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Apr 11, 2014 11:59 AM
>To: Randy Presuhn <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [netmod] new issue: configuration versus state data
...
>I agree the concept of state datastore is not completely straightforward but
>
>- it is even worse to assume that it is a super-tree of the configuration tree,
>
>- a hierarchical data structure seems to be quite common - YANG, MIB, /proc, most CLIs.  
...

It's an annoyance, but I don't see that aspect of the problem as
being substantially different from what is faced by the (sub)agent
developer for any other protocol: one must realistically start with
the assumption that the interoperable model will differ from managed
resource's native representation. Sometimes a little, sometimes a lot.

If you're lucky, those differences will be mostly just how the bits
and pieces are identified and organized; those mappings are easily
dealt with in code-generating tools with the help of developer-provided
hints.  Systematic mappings between data types are also tractable.
Where it gets messy (as in some of the cases you alluded to) is when
there are real differences in the semantics (including side-effects)
of multiple models/protocols accessing what should be the same
underlying information.

I guess it depends on what one's expectations / vision for
netconf-based management are.  If one is just looking for a
way to deliver more-or-less proprietary blobs of configuration
data, the expectations will be considerably less demanding
than those of someone looking for a full-blown management
protocol or an actual configuration management tool.

Part of what it sounds like you're asking for is a better
integration between the protocol and the yang meta-model.
The difficulty is that the latter doesn't seem to have been
worked out, and I'm sure some folks would say that this
is by design, and a feature rather than a bug.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Apr 2014 14:48:14 -0700

On Fri, Apr 11, 2014 at 1:07 PM, Randy Presuhn <[email-masked]
> wrote:

> protocol or an actual configuration management tool.

Getting vendors to agree on standard configuration will take time.
There will always be a mix of standard and vendor modules,
just like with SNMP/SMIv2.

> is by design, and a feature rather than a bug.
There are many aspects of network operations that are left to
vendor implementation.  So what? Commercial engineering can be
more messy than it should be (as envisioned by the computer
scientists who don't have to get the code done ASAP. ;;)

> Randy

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Apr 2014 13:39:14 +0200

> of multiple models/protocols accessing what should be the same

I'd say the size of this problem is comparable to finding a common denominator for CLI data models of different vendors, i.e. something we've been dealing with in the past few years (I am not saying we've succeeded with that).

> protocol or an actual configuration management tool.

In my view, the prospect of uniform remote configuration is quite appealing to operators but much less so to equipment vendors. What's actually happening is that new protocols are being designed whose main selling point is uniform (partial) configurability, and where a common data model could in fact suffice. Recent examples are OpenFlow and I2RS.

> integration between the protocol and the yang meta-model.

I think I am rather asking for *decoupling* the protocol (NETCONF) from the YANG meta-model. Apart from some NETCONF-centric formulations in RFC 6020, it is the "config" statement and the option of embedding state data inside configuration that makes it difficult for other protocols to share state data with NETCONF in a safe and transparent way.

Lada 

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

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