Subject: [netmod] YANG extensions

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 Aug 2013 18:50:07 +0200 (CEST)

Hi,

I'd just like to comment on Kent's last comment in the session today.
He said that Juniper tried to use YANG, but it wasn't suitable, so they
had to add all kinds of YANG extensions.

First of all, it is important to understand that YANG's extension
mechanism is very powerful, but it be disastrous to interoperability
if not used carefully.  The way to think about an extension is that if
a client does not understand the extension, the clienbt should still
be able to communicate with the device correctly.  For example, adding
an extension to make a key in a list optional would break
interoperability, but adding an extension that classifies a config
false node into operational state and statistics would not.  (I am
specificially referring to NETCONF interoperability here).

(We have one extension that breaks this rule, and I truly regret that
we added it - it has caused much more trouble than it solved)

Second, it would be interesting to know what you meant when you said
that it was not suitable.  If you meant that you could not use YANG to
describe all your *current* behavior, it is not all surprising
(well...).  But if you meant that the YANG-defined behavior is
completely unacceptable (even if it wasn't for backwards-compatibility
with you current behavior), it would be very useful to know what it
is.

/martin

---

From: David Harrington <[email-masked]>
Date: Fri, 02 Aug 2013 09:28:15 +0200

Maybe YANG is just not a suitable choice for the use case in mind, and
making YANG suitable for that use case could break YANG for other use
cases for which YANG was designed ...

It would certainly be useful to understand the use case for which YANG is
considered not suitable.

I say this partly in response to yesterday's meeting, where people from
other WGs seem to have whole new areas of usage that YANG and Netconf
weren't designed for specifically, and the answer to the unsuitability
seems to be to redesign YANG and Netconf to meet their specific needs.

--
David Harrington
[email-masked]
+1-603-828-1401

On 8/1/13 6:50 PM, "Martin Bjorklund" <[email-masked]> wrote:

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Aug 2013 14:03:50 -0700

Hi,

This thread is a whole lot of hand-waving, and not at all useful,
except Martin's advice on extension transparency.

NETCONF deals with a single server, so I am not sure why we
need YANG extensions to replicate configs across a cluster.
I think the "YANG Mount Point" draft is probably a more comprehensive
solution to complex config distribution across multiple servers.

The biggest complaint I hear from customers about YANG is
the choice-stmt.  There are many situations where deleting
the old case when a new case is selected is not desirable.
IMO, the conditional enablement draft offers the best solution
for maintaining data node states other than "active".

The notion of using 1 YANG "template" to generate N different variants
may be beyond the scope of YANG, but also something customers want.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 Aug 2013 14:51:16 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "David Harrington" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, August 02, 2013 2:03 PM
> Subject: Re: [netmod] YANG extensions
...
> need YANG extensions to replicate configs across a cluster.

I think you just anwered your own question here.
But I think it's more than just replication across a cluster,
which might potentially be handled by the cluster itself.

>From the perspective of *network* operation,
configuration is not about a single server's configuration,
but rather about a set of communicating systems.
To the extent that NETCONF still doesn't really address
*network* configuration, folks will continue to try to bolt
it on through extensions and ad hoc model work-arounds.

> solution to complex config distribution across multiple servers.

Providing a coherent framwork for operating on the set of device-specific
configurations that collectively constitue a network's configuration would
be the next logical step.  Unfortunately, I don't see how netconf's
naming architecture woud facilitate such a thing.

> for maintaining data node states other than "active".

Analogous to the source-code problem (or non-problem, depending
on how one looks at it) of #ifdef, commented-out, and "dead" code.
 
> may be beyond the scope of YANG, but also something customers want.

For a long time configuration data has included scripts and code.
"Conditional enablement" is just a really degenerate case of that.
I think when reasoning about the configuration of a system it's
important to be able to distinguish between the configuration data
and the results of evaluating that configuration data in a particular
system in a particular operating environment at a particular point in time.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Aug 2013 15:20:04 -0700

> which might potentially be handled by the cluster itself.

Network-wide config is a harder problem than cluster mgmt.
A cluster is a set of switches being managed as if it were
a single server.

Since NETCONF is a protocol between a single client and a single server,
it will probably take more than a minor tweak to support network-wide
configuration correctly.

> it on through extensions and ad hoc model work-arounds.

I don't see this as a defect in NETCONF.  It does what
it was designed to do, and new functionality will
require new work.

> naming architecture woud facilitate such a thing.

not sure what this means -- I agree that the NETCONF datastore is
associated with a single server.  Not sure how data naming could change
in a way that does not break old clients.

> on how one looks at it) of #ifdef, commented-out, and "dead" code.

The conditional enablement draft has several types of config state
that allow much more than #ifdef functionality, such as time-based
and event-based triggers.

> system in a particular operating environment at a particular point in time.

A comprehensive YANG pre-processor would be a useful tool
for complex variance mgmt -- much better than YANG deviations.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 03 Aug 2013 09:33:52 +0200 (CEST)

> need YANG extensions to replicate configs across a cluster.

Where did this come from?  I see two messages in this thread (one from
me, and one from David), and neither mentions clusters.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 3 Aug 2013 09:44:21 +0200

It was discussed in the meeting. 

Sent from my iPhone

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Aug 2013 11:13:28 +0200

> the old case when a new case is selected is not desirable.

I objected repeatedly against this kind of behaviour (also in connection with "when"). It is not server's business to tinker with configuration - it should be client's responsibility to prepare a valid configuration, and the server should only accept it or reject. So it in not a fault of the choice statement.

> for maintaining data node states other than "active".

I think this cannot be considered a replacement for "choice".

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Aug 2013 11:21:19 +0200

> system in a particular operating environment at a particular point in time.

Right, so it again comes down to the distinction between configuration and state data or, more precisely, to the process of mapping the former to the latter.

Lada