Subject: [netmod] defaults and offline validation

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Aug 2008 14:01:14 -0700

Hi,

I know this is a sore topic, but an important one.
An important use-case for with-defaults=true is
the off-line validation of database changes by a manager.

A manager should be able to retrieve all the agent
schema-discovery data, and a complete <get-config>.
Given the YANG modules that the agent is actually using,
plus a complete <config> element, a manager
can perform all the 'must', 'when', and 'unique'
tests (along with all the value checking tests).
(OK, add in Martin's platform 'overlay' and the data is complete.)

However, if the must and when XPath expressions break
if a leaf contains the agent default, and works if
the leaf contains a manager value, then the value of
these statements is severely diminished.

Or, if the XPath magically works on the agent, but nodes referenced
in the XPath expression do not get returned in the
<get-config> because they are the default value,
then the same XPath will not work on the manager.
This breaks the manager's ability to test config
changes offline.

IMO, this is an important feature.
(Not everybody just flings commands at a router
to see what will happen ;-)

Andy

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

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Aug 2008 11:46:45 -0400

>This breaks the manager's ability to test config

The mgmt app can use the defaults from the YANG module and the
device deviations to test config changes.   Additional default
values will likely not matter to the model and the constraints
therein.

>to see what will happen ;-)

But this is exactly what you are doing.  You are wanting to throw
config at a router, fetch it back with a flag to get all default
values, and then validate it.  You are flinging config at the router
and then seeing what you made.

I'm fine with adding the flag, but I don't see it as a valuable
replacement to knowing the default values _before_ I throw the
config at the router.

Here's a dumb never-gonna-happen example:  The IETF-USER module
says users have a default password of "*", meaning unusable.  Someone
makes a box with a device deviation that gives a default password
of "" (the empty string, no password needed).  Wouldn't you want
to know the _before_ you make a user instance that depends on the
default password value?

A with-defaults flag might be useful to know what someone else made,
but it's not useful to know what you are going to make if you fling
config at a router.  You find out what you made after you made it,
which is a bit too late.

I have a "show | display defaults" command in my code, so users
that don't want to look up defaults can see what they've made, but
while a user may want to avoid looking up the default, an application
shouldn't.  Users are lazy.  Applications shouldn't be.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Aug 2008 09:24:15 -0700

> values will likely not matter to the model and the constraints

I do not see how the application is going to use
off the shelf tools like libxml2 to test all the
must and when XPath expressions.  If the default node is
not in the instance document, the same XPath expression
that worked by magic on the agent does not work at all
for the manager.

> and then seeing what you made.

No.
I said <get-config>.
Given the complete <get-config> output and all the YANG modules
and vendor overlays, an application can test some
operator config changes off-line to see if the
<edit-config> or <commit> should work on the agent.

A manager could use <validate>, but this is optional,
and not actually required to do any specific tests at all.
If the <candidate> is available, you can fill up
that sandbox and fling it at the router with <commit>.
But if <candidate> is not supported, the manager is SOL,
and needs an off-line sandbox.

> shouldn't.  Users are lazy.  Applications shouldn't be.

How does the manager know the default values for the nodes without
a YANG-specified default, in advance?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Aug 2008 12:32:42 -0400

><edit-config> or <commit> should work on the agent.

Completely agree.

>and needs an off-line sandbox.

Completely agree.  And the YANG module plus the device deviations
should be sufficient to drive the off line sandbox.

>a YANG-specified default, in advance?

Device deviations.  If the device adds a default value to
the standard, it can announce it as a device deviation.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Aug 2008 10:28:53 -0700

> the standard, it can announce it as a device deviation.

A lot of custom code to reconstruct the <config>
element is needed with this approach.

Several people (including me) do not see the need to
make such a big deal out of config leafs which happen
to contain the default value.

Sometimes optional leafs (with or without YANG defaults defined)
are really not there in the agent.  Not used.  Not implemented.
Nowhere to be found.

Sometimes optional leafs (with or without YANG defaults defined)
really are there in the agent.  It depends on the data model,
as to what the default means and whether or not it
makes sense to create an instance or that leaf.

Sometimes defaults like 'off', 'disabled', etc. amount
to the same thing as if the leaf was not there.  But
defaults like '1500' for MTU or 'root@localhost' for
sysadmin-email-address are not just placeholders.

I will continue to use <get-config> (+with-defaults=true)
to deal with this problem.  I want a single XML tree from
the agent that has the nodes the agent is using, and does not
have any nodes it is not using.  <get-config> already
provides that, without any new work required.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Aug 2008 13:47:13 -0400

>element is needed with this approach.

s/reconstruct/pre-construct/

Doesn't seem that hard to me.  You are merging the tree of "stuff
you want to make" with "defaults you learn from modules and
deviations".  Traverse the tree, if a node isn't there and has a
default, add it.

>have any nodes it is not using.

This works for after-the-fact validation.  If you're happy with
that, a with-defaults capability will satisfy you.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Aug 2008 11:26:21 -0700

> that, a with-defaults capability will satisfy you.

this works for taking the running config
from a particular known good state to a different good state.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Aug 2008 12:07:29 -0700

> deviations".  Traverse the tree, if a node isn't there and has a

Within your agent implementation, you know
whether or not any leaf is being used or not,
and if it being used, you know the internal
(or manager-supplied) value.

It is easy to code 'with-defaults', so it should
be no problem to support both types of validation:
1) device is not available for validation
2) device is available for validation and possibly
    already part of a running network

You cannot evaluate the must and when statements without
a <config> element to test against.

Andy