Subject: Re: [netmod] Configuration nodes was Re: meaning of defau

From: David Partain <[email-masked]>
Date: Wed, 2 Sep 2009 13:10:40 +0200

Hi,

On Friday 28 August 2009 09.37.12 Andy Bierman wrote:
> Phil Shafer wrote:
> > Andy Bierman writes:
> >> If the server can synthesize the value of a leaf for the purposes
> >> of validation and XPath, that it can do the same for the
> >> purposes of retrieval.
> >
> > We've traveled this road before.  The issue isn't that the server
> > cannot supply default values, it's that it should not supply them.
>
> Again -- it is up to the client to decide what
> the client wants to retrieve, not the server.

My take is that we really need :with-defaults...

> Again -- documentation for what the server should contain
> is not the same as retrieval of the data that the server actually contains.
> Documentation is purely optional in YANG anyway.

Andy, you keep talking about "offline documentation" or "vendor 
documentation".  I'm clearly missing something.  I don't see that we're 
talking about "vendor documentation" but rather the YANG data model.  You 
can't do anything rational with SNMP without the MIB, either. If the client 
doesn't have the YANG data model, we're trashed anyway, aren't we?  Why is it 
so onerous to look at what 'default' statements are in the data model?

Thanks.

David

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 05:45:27 -0700

> My take is that we really need :with-defaults...

I think it was much cleaner as a boolean.
Retrieve YANG defaults? (yes/no) [d:no]

> so onerous to look at what 'default' statements are in the data model?

IMO, this is more complicated to use, and not nearly as robust as SNMP.

As Tom alluded to, you have to save the server capabilities
and extracted defaults out of the YANG modules+deviations,
along with the 'real' data, just to backup a configuration.

You need very complicated software and a deterministic set of
meta-data just to extract the current configuration/state/whatever
from a device.

The only way to be sure a device is using the default is to set
every server-assigned leaf to its default, just so you can read back
the value you set.  This is extra work on both ends for no reason.

The deviations and no-revision-is-OK problems make the meta-data set
almost deterministic and almost complete, at best.  That's not good
enough for backup purposes.

I have not met anybody (so far) that believes for a second
that vendors will publish their deviation files, so relying
on deviations (especially in the critical path) seems
problematic to me.

> David

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 10:38:46 -0400

>meta-data just to extract the current configuration/state/whatever

I know I've said this before, but I guess it's been a while....

There is a lot of complexity in configuration management.  There
is no pixie dust that will remove that complexity.  The only
question is where do we want that complexity to live.

Previous attempts have always tried to push the devices into a
single model, allowing the application to make simple assumptions
about how a device can be treated.  This puts the complexity
for deciding how to deal with differences between the model
and the device rules onto the device side.

Complexity on the device side has a number of costs:
(a) stale software
    no one upgrades deployed devices to fix NM software
    ex: JUNOS has an ancient SNMP bug.  Customers report it
    but do not upgrade to get a fix.  The risk/reward isn't
    there.
(b) ambiguity
    if the model doesn't match how the device works, the
    device must make assumptions to wedge the model into
    the device's mode of operation
    ex: distinct startup; if I make a config change on
    a box with distinct startup, should that change be
    written to startup?  If the app isn't aware of the
    :district-startup capability, how can the device
    know enough to do the right thing?
(c) flexibility
    if the device is more flexible than the model, the
    device has to map the model into its native capabilities.
    This is not a trivial job and impossible to do right.
    ex: JUNOS has 5 ways of doing firewalling, with tradeoffs
    for speed and features (line rate for looking at packet
    headers, but smart card/embedded processor for deep packet
    or flow-based filtering).  If a client makes a filter, the
    device would guess which features are needed and which type
    of filter to use, but not easily.  Add multiple smart cards
    and guessing at load balancing is impossible.
(d) constraints
    if the model allows something that the device simply cannot
    do, the device can either fake it, or not support the model.
    ex: if the model has a counter which the device hardware does
    not contain, the device will not have a value for that counter.

In NETCONF/YANG, the operating model is different.  We are saying
that putting complexity into the client application is a Good Thing.
Allowing the device to express its native capabilities is a Good
Thing.  Letting the application know explicitly how the device works
and what needs to be done to get the device to behave in the way
the application wants is a Good Thing.

By shifting the complexity to the device, we knock out all these issues.

Yes, the client side may be more complex, but this is only true if
the client was simple enough that it never needed to understand
what was really going on in the device.  And what value is a
config app that doesn't grok distinct-startup or candidate?

So it's not a matter of "mandatory true" adding complexity, but a
victory in that both sides of the exchange can understand that this
is mandatory and behave accordingly.

Are you sure I can't put these thoughts back in the arch draft?

>the value you set.  This is extra work on both ends for no reason.

ABS leafs do not have default values.  Leafs with default values
never need to have that default value assigned.  There is no extra
work on either end.

>on deviations (especially in the critical path) seems

So start deviations-central.com and have folks contribute open
source deviation files.  When the list is made, there's no value
in having the vendors mask their own deviations.  It's not a secret,
so the impact of publishing it is low.

In other words, having a mechanism for describing what's broken
allows the list of what's broken to be maintained by any responsible
party.  Such a list allows the application to have a better feel
for what will work and what won't.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Sep 2009 08:24:40 -0700

> I know I've said this before, but I guess it's been a while....

Being able to retrieve all the data from a device
is not supposed to be this complicated.  Using any
software at all to synthesize data instead of collecting
it doesn't even count as an backup or a verification mechanism.

If you have the naming and the all raw data, you can enable
archiving, and history collection, etc., on dumb
little middleware devices, and use the complex bloated code
to analyze the collected data.  Even if monitoring does
not matter, a full snapshot of the config+state does matter.

Instead, in YANG/NETCONF, you have to save the data,
save all the <hello> information (w/ features, deviations, revisions),
make sure all those YANG modules are available, compile the YANG modules,
process the <hello> PDU, apply the deviation patches,
and enable the advertised features, synthesize the missing
leafs, and then insert them where they go in the tree.

All this, for what?
To save bandwidth?

If operators have to rely this heavily on tools
just to get the data, they can rely on tools
just as much to read the data.  The application
can prune the defaults, color them orange, or whatever.

I don't understand why we are trying so hard
to solve a presentation layer problem in
the configuration protocol.  The result is
a complicated mess.

Andy

---

From: "tom.petch" <[email-masked]>
Date: Wed, 2 Sep 2009 16:03:19 +0200

----- Original Message -----
From: "David Partain" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 02, 2009 1:10 PM
Subject: Re: [netmod] Configuration nodes was Re: meaning of defau

> can't do anything rational with SNMP without the MIB, either.

Well, I have, when trouble shooting.  Given a MIB walk, I can get objects
defined in a proprietary MIB module, name, OID, syntax, value, construct
tables where necessary and, assuming the MIB module writer thinks the
same way as I do (might have been AB), take a view on what is going on.

I much prefer to be able to download the MIB module from the web and
compile it, which is mostly possibly nowadays, and if the DESCRIPTION
clauses are good, then I can do more.  And if the tool writer has already
done that and given me a GUI, better still.

Netconf/YANG, as currently proposed, will give me much less data
which, when everything is working perfectly is fine, but when things
are going wrong, I prefer more to less.

This is Operations Management.  Configuration Management is
different - there I want the device to tell me what has been set
so I can backup and restore a configuration; for that, a MIB walk
is a nightmare.

Tom Petch

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

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 11:44:56 -0400

Andy Bierman writes:
>is not supposed to be this complicated.

Sorry, but YANG doesn't make retrieving configuration data complicated.
The stock <get-config> operation works perfectly.

But retrieving is trivial.  The meta-data is meant to answer questions
like "what does it take to make a valid member of this particular
list".  To answer that, you need keys, mandatory, musts, etc.  YANG
gives you all that.

>the configuration protocol.  The result is

The question "what is the configuration data for this box" isn't a
presentation layer issue.  And I disagree with your conclusion.  If
you just want config for archival and restoring, use the stock
NETCONF <*-config> operations and be happy.  If you need richer
meta-data, use the YANG modules and be very happy.

Thanks,
 Phil