Re: [YANG] mandatory & default

[Phil Shafer <[e-mail]>]

[replying to multiple Andy-grams]

Andy Bierman writes:
>Whether the manager or the agent sets the leaf to the default,
>it is there from a NETCONF protocol PoV.

NETCONF leaves all this to the data model, so there's no single
NETCONF POV on this issue.  This is designed to support existing
views of configuration issues, including defaults.

>It is an implementation-specific matter as to how
>an agent generates a reply to a <get-config> request.
>The defaults do not have to be stored -- they can
>be generated on the fly.

If I'm using NETCONF to archive configurations, I don't
want them littered with defaults.  Similar for if I'm
viewing them in the equivalent of a mib browser.  I want
to see the statements that someone has explicitly configured,
not volumes of uninteresting defaults.

Part of putting these values into YANG modules is to allow
interested parties (applications, developers) to know these values
as they are helping the user create new instances.  To my mind, the
"with-defaults" is useless for this scenario, since I want to know
the defaults _before_ I make the config, not after.

The KISS view of config is used for CLIs because is keeps the
noise to a minimum.  This need doesn't disappear when the
config moves into the application/automation world.


>Message-ID: <[e-mail]>
>Date: Fri, 25 Jan 2008 16:06:53 -0800
>From: Andy Bierman <[e-mail]>
>
>After a system reboot, does the agent 'remember' that mtu
>was set to 1500 by the manager, so the initial <running/>
>config from NV-storage after the next reboot has an mtu leaf
>for eth1?

No, the system records as the configuration only those fields which
are interesting.  For example in JUNOS, we define "interesting" as
anything the user told us to do.  In IOS, they define "interesting"
as any non-default values.  IMHO, you're trying to define interesting
to include some very boring defaults.


>Message-ID: <[e-mail]>
>Date: Sat, 26 Jan 2008 07:01:57 -0800
>From: Andy Bierman <[e-mail]>
>
>But here is where this CLI-based design is broken.
>If a manager sends jumbo packets on eth1, they will not be accepted.
>There is a maximum transmission unit size in effect on eth1,
>but the manager is told there is none in the <get-config>.

The application can find all the information about "mtu", including
its default value, in the metadata.  The application can show this
default value to the user as they create a new interface, and the
application can know that if there's an <mtu> in the interface, its
there because someone wanted it, and that's it's not noise.

>The response "oh no, there is an MTU value in effect, just not in the config"
>is really broken.  It's not state data, and it's not config data, but if
>the manager does not know the value, it cannot reliably configure other
>devices that send packets to 'eth1' on this agent.

Nope, it's not config data.  It's a default value.  The device
doesn't need it to perform the job of configuration, which is
defined in the NETCONF spec as:

   Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.

Default values aren't required in config data.  Or wanted.

If I've got 64,000 interfaces, I don't need to see this default
value for each interface, let alone the hundred other knobs for
each interface that have perfect reasonable and completely
uninteresting default values.

>IMO, the mtu is clearly config data, and clearly in effect at
>all times eth1 is accepting packets.  The config returned
>in NETCONF PDUs should match.  Filtering out these defaults
>is a separate issue from whether they exist or not.

The issue isn't filtering them out.  The issue is are defaults part
of the configuration?  I understand the need for a mechanism for
discovering them, both inline and in metadata, but I don't see any
win in considering such noise as part of the configuration of a
device.

We are working hard to make devices _more_ managable.  Adding a
couple of orders of magnitude of noise into the configuration
means:
- performance issues (as my 1m config turns into 100m)
- upgrade/downgrade issues (as defaults for unused features break
  on software that doesn't support them, even if they are completely
  unimportant)
- readability issues (as adding noise makes the config less readable
  and the purpose of using xml was human readability for debugging
  and monitoring)

Inline defaults is broken, to lift your words, since it takes a
complex problem and makes it more complex.  We should be simplifying,
reducing, and giving better visibility into the important parts of
configuration, not polluting them with noise.

Thanks,
 Phil


_______________________________________________
YANG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/yang