Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03

From: Kent Watsen <[email-masked]>
Date: Thu, 24 Sep 2009 17:01:28 -0700

Hi All,

My primary comment is that, when using "report-all", the client has no way of knowing which values were explicitly set without also getting the "explicit" config, which would be a waste of bandwidth...

A simple fix to this is to have "report-all" mark the default nodes with an attribute indicating just that.  For instance:

  <mtu is-default="true">1500<mtu>

This approach not only resolves the issue mentioned above, but it also allows the output to be fed directly back into an <edit-config> operation without worries of the device creating a bunch of user-defined nodes in the config tree

What do you think?

Thanks,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Sep 2009 09:38:32 +0200

Kent Watsen píše v Čt 24. 09. 2009 v 17:01 -0700:
> Hi All,
> 
> My primary comment is that, when using "report-all", the client has no
> way of knowing which values were explicitly set without also getting
> the "explicit" config, which would be a waste of bandwidth...

Is this something that the client has to care about? In my view, it is
sufficient to know that a certain value is there.

Lada

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Sep 2009 10:01:38 +0200 (CEST)

> sufficient to know that a certain value is there.

The information is there primarily for the server, so that when it
receives a leaf marked as is-default="true" in an edit-config, it can
ignore the leaf.

But I'm not so sure that this extra meta-data solves any problem.  If
we stick to the idea that a server that implements the explicit mode
does not have to send default values back, it means that it is safe
for a client to do save / restore on the same type of devices, even
w/o this meta-data.

A related problem with this meta-data is that it forces report-all
devices to keep track of who created the leaf, (essentially making
report-all devices implement the explicit mode), which goes against
the original use case, i.e. that there are implementations which
cannot distinguish between leafs that have been explicitly set and
leafs which have their defaults (if they could, we could require
everyone to implement the explicit mode).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 02:07:30 -0700

> everyone to implement the explicit mode).

For implementors of explicit mode, they must keep a bit
for 'server-set' or they could not save to NV-store properly.

Another issue: explicit mode has no relationship whatsoever
with the YANG default value, so tagging all server nodes
as 'is_default' is misleading.

YAI: YANG doesn't support XML attributes, so we can't
actually use YANG to model this attribute (modulo the
extension hack used for <filter>).

YYAI: The client may not want this tagging, so 2
modes for report-all are needed.
Perhaps a new enum called 'report-all-tagged'?

Before I was thinking that a client would risk
having the config change underneath if 2 get-config
requests were needed:

   defaults = get-config(report-all) - get-config(trim)

But I forgot that the client can just lock the config first,
so the config will not change between the 1st and 2nd get-config.
Now this 'is_default' tag seems nice-to-have, but not critical.

> /martin

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Sep 2009 11:20:33 +0200

> extension hack used for <filter>).

Actually, this would be a good use of XML attributes and it could be
defined in the specification of the mapping from the conceptual data
tree to the "explicit" view of the datastore, not in core YANG.

> Perhaps a new enum called 'report-all-tagged'?

If the client asks for "explicit", it should be prepared for handling
these tags, and they should not appear in the "report-all" and "trim"
views. If the server doesn't support with-defaults and uses "explicit",
this information may get lost.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Sep 2009 12:19:51 +0200

> for a client to do save / restore on the same type of devices, even
 
The proposal essentially avoids having clients computing diffs between
report-all and explit configs. This is nice but it opens up the floor
for attributes and meta data in XML content, perhaps something we like
to avoid / postpone at this point in time.

> everyone to implement the explicit mode).

Everyone supporting explicit would be a win if you ask me. Perhaps we
should have a poll to see how many actually would not be able to
support explicit. And we should kill trim - I do not see why someone
would want that operationally.

/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: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Sep 2009 13:38:56 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> views.

It must be the other way around.  The original idea was to use this
attribute to distinguish between defaults in effect from explicitly
created values.  So if report-all still just sends everything w/o this
attribute, we havenät solved anything.  And explicit is defined to NOT
send defaults.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 25 Sep 2009 08:25:18 -0400

>would want that operationally.

I'm all for "explicit" and consider it the best solution, but "trim"
is the mechanism used by IOS and IOS-like devices, where setting a
leaf to the default value causes the leaf to disappear (when the
central OS asks a component to report its config settings, the
component reports any non-default values, but does not retain a bit
to say whether the default was explicitly set or not).

I would assume that removing the ability to take the "trim" approach
would significantly increase the implementation cost (and reduce
the compliance) of such vendors, so keeping it makes sense in
maximizing the market adoption of YANG.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 07:19:21 -0700

> would want that operationally.

The NV-storage is linked to with-defaults.
The WG decided the operator should have no control
over this at all (remember with-defaults for
copy-config to startup?).  Now the 'basic' with-defaults
behavior controls how NV-store works.

This is left up to the server implementation
and should stay that way. Defaults
across reboots sometimes change if the device
SW image changes, or the device itself changes
(hotswap, plug-in module, etc.)

Blindly trusting defaults works great until it stops
working great, and then you have to fix it.

This is just another capability the client needs to deal
with amongst dozens of them.

FWIW, in my code this is all configurable,
plus there is a special RPC (set-my-session)
that lets each session set their own default
for with-defaults, instead of using the
parameter leaf.

I think the 'basic' behavior should remain configurable
by the operator, not hard-wired to 'explicit'.

Andy

---

From: WashamFan <[email-masked]>
Date: Fri, 25 Sep 2009 22:49:54 +0800

>    defaults = get-config(report-all) - get-config(trim)

I'd like to add:

explicitly set defaults = get-config(report-all) - get-config(explicit)
operationally used defaults = get-config(explicit) - get-config(trim)

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Sep 2009 17:07:06 +0200

> by the operator, not hard-wired to 'explicit'.

Still if would be cool if every netconf server would allow me to use
explicit mode if I choose so... But I might be dreaming.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 08:28:47 -0700

> explicit mode if I choose so... But I might be dreaming.

Yes -- I realize now why it is the best for normal use.
Even if a YANG default changes across reboots, the explicit
config doesn't change.   For that reason alone, it is way
better than 'trim'.

IMO, 'report-all' is really for diagnostic mode,
not normal mode, but maybe not.  It is wrong to assume
that NV-storage of 1 XML file is somehow a burden for
every platform running NETCONF.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 25 Sep 2009 11:57:43 -0400

Andy Bierman writes:
>It is wrong to assume

Well, it's wrong to assume that a platform running NETCONF uses XML
for anything more than parsing content off the wire.  The JUNOS
config database is not XML, nor are our NV-storage contents.

Also the storage needs for "explicit" or "trim" are not similar to
"report-all".  For example, the JUNOS list element for static routes
has nearly 75 leafs under it, of which 2-3 are typically set.
Assuming they all have default (which they don't, but...), the
customer that loads 50,000 static routes has a impact (with 32 bytes
overhead per list instance plus, say, 12 bytes per leaf instance)
of 2.8M for explicit and 46.6M for report-all.

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Sep 2009 12:22:54 -0400

I think I agree with what I think you mean :-)

In your example, if a client took a report-all output and fed it back, 
and assuming that the system internally uses an explicit model which I 
think you have said, then the config storage for this case goes from 
2.8M to 46.6M.  Is that the point?

Otherwise, I am very confused.

Or are you talking about the size of the output if a client requests 
explicit vs report-all?  That difference is the client's problem they 
asked for it, give it to them.
And, unless someone does the feedback above, your box can presumably 
happily produce a report-all output even if it stores only explicit.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 09:28:20 -0700

> config database is not XML, nor are our NV-storage contents.

This is fine as long as you don't use a
distinct startup config (and you don't I think).
If the startup is saved via copy-config from
running to startup, then (IMO) it must be in
the same format as a <get-config> would return.

> of 2.8M for explicit and 46.6M for report-all.

I agree that 'explicit' is the best for NV-storage.
The operator picks what is saved, not the server,
and that is key.

But XML compresses well if you care about Flash write
times and limited capacity.  XML filesize is a non-factor
if there is a hard drive instead of Flash memory.

At 10 cents a megabyte (retail) and falling, this will
become less and less of an issue over time.  Moore's law
is working faster than the configs are growing.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 25 Sep 2009 13:55:43 -0400

>distinct startup config (and you don't I think).

Even distinct-startup does not require that the format on the disk
be XML.

>is working faster than the configs are growing.

Sure, but in the end, some bean counter decides how much flash a
device gets and the rest of us have to live with it.  (Not that I'm
bitter ;^)

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 25 Sep 2009 13:59:11 -0400

>I think I agree with what I think you mean :-)

Sorry if I overtrimmed Andy's comment.  He said maybe it didn't
matter if the device had to save the config in report-all, full of
defaults style, and my point was that it can eat an order of magnitude
more flash/disk space, which isn't an unlimited resource.

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Sep 2009 14:29:10 -0400

Thanks.  That's what I thought you meant.
Joel

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 12:16:19 -0700

> Even distinct-startup does not require that the format on the disk

Some of us think that is a bug, not a feature.

Do we need a separate RFC to say that a standard
NETCONF config file is an XML instance document containing
the <nc:config> element?  I was hoping we could put
that in 4741bis.

> device gets and the rest of us have to live with it.  (Not that I'm

yep.  And they always want to give 'flash upgrade options'
super high markups, so you really are stuck with too
little NV-store most of the time.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 25 Sep 2009 12:10:38 -0700

> for a client to do save / restore on the same type of devices, even

Already a server supporting "explicit" is not required to support "report-all", but what if it does?  - then aren't the defaults required to be returned?

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 25 Sep 2009 12:13:53 -0700

> Andy Bierman wrote:
> IMO, 'report-all' is really for diagnostic mode, not normal mode, but maybe not.  

Yes, for management applications, where development effort will likely be extended to be meta-data aware.  But what about simple scripts?  A script needing to act on the conceptual tree (i.e. includes defaults) would use "report-all" and, when submitting the change back to the device, could unknowingly create a bunch of explicit nodes...

Maybe the questions is - how likely is it that a server supporting "explicit" would also support "report-all" and a client would use the output of report-all as input to <edit-config>?  Also, we could ask about the worst case scenario (2.8M --> 46.6M) - hope the device includes a rollback feature ;)

Thanks,
Kent

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Sep 2009 12:25:09 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, September 25, 2009 12:16 PM
> Subject: Re: [Netconf] review of draft-ietf-netconf-with-defaults-03
...
> the <nc:config> element?  I was hoping we could put
...

Conformance to the protocol should not dictate the format a system
uses internally.  If folks think it is desirable to have a specification of
a "standard NETCONF config file format", fine, but conformance
to that specification should be kept completely independent of
claims of conformance to the protocol, in the same way that
conformance to AgentX is a completely separate question from
whether a system conforms to the SNMPv3 specifications.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 12:55:28 -0700

> whether a system conforms to the SNMPv3 specifications.

OK -- so you are saying we need a separate RFC for
the standard file format for the XML representation
of a NETCONF database.

This is useful to have if NETCONF reaches any level
of interoperability at all.  If 2 compliant servers
both support the same set of YANG modules/revisions
represented in the XML document, then a startup-cfg.xml
for one device should work on the other.

(Sorry if this level of interoperability is too bizarre
to comprehend in the embedded NM world. ;-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Sep 2009 22:21:37 +0200 (CEST)

"Randy Presuhn" <[email-masked]> wrote:
> uses internally.

+1.

In this particular case, as long as <get-config> on startup produces
the correct XML, it doesn't matter what form the data is stored
internally.

However, the format of what goes into a URL file used by <copy-config>
isn't specified, but should be (see
http://trac.tools.ietf.org/wg/netconf/trac/wiki/Issues_4741bis#issue-012).
This still just means that the format produced / consumed by the
<copy-config> is well-defined; it doesn't mean that the file format
MUST be the same.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 13:46:21 -0700

>> Conformance to the protocol should not dictate the format a system

IMO, it is useful for the NETCONF architecture to consider
how a device handles a startup sequence from factory-default,
or just a normal reboot.  SNMP failed to recognize many operational
aspects of NM, including the startup config.  NETCONF addresses some
of it and ignores the rest.  Since every server is required to support
a copy-config(inline) to its write-target (candidate or running),
it seems pretty easy to support the same format for NV-boot,
at least at the conceptual level.

> <copy-config> is well-defined; it doesn't mean that the file format

If an XML file from one copy-config doesn't
work with copy-config on a different device,
then NETCONF fails to meet a very important
requirement identified by operators at the IAB NM Workshop --
the one that led to separate <get-config> in the first place.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Sep 2009 23:04:18 +0200 (CEST)

> at least at the conceptual level.

On the conceptual level, absolutely.

> the one that led to separate <get-config> in the first place.

That's what issue 12 above is about.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Sep 2009 23:26:50 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> config doesn't change.

Currently, the upgrade rules do not allow a default value to be
changed.  Do you think it would work to allow that?  It is not
uncommon that it happens...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Sep 2009 18:27:07 -0700

> uncommon that it happens...

I brought up the issue that the rules let a refine-stmt
change the default in a grouping, but one could argue
that the leaf in the grouping is just a template, not
an object, so the same rules do not always have to apply.

I wish that were the case, because moving between inline
and uses versions should be transparent to the syntax
and the semantics, but they really aren't.

If revisions were mandatory to use and advertise, then it
would be reasonably safe to change a default in a new
published version.  IMO, a standard module would have
to go back to Proposed Standard in order to do that.

   leaf most-of-the-time {
      type string;
   }

IMO the most likely scenario is no static default,
and mandatory=false.  Vendors will be reluctant to document
their defaults added via deviations.  If the
new server-assignable=true, then the client
may have to rely on get-config with-defaults=report-all
to learn the dynamic defaults.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Sep 2009 22:40:30 -0400

As far as I know, if a node is server assignable (and with no default 
specified), then if the server assigns it a value, then the node is 
returned in a regular get-config.  There is no need for with-defaults 
because that value is not the value defined by the default clause.

At least, that was how I understood the last explantion from Martin.

Yours,
Joel

---

From: Phil Shafer <[email-masked]>
Date: Sat, 26 Sep 2009 15:16:10 -0400

>At least, that was how I understood the last explantion from Martin.

This is exactly correct.  Anything that is system-assignable
won't it have a default value (nor will it be mandatory).

Thanks,
 Phil