[YANG] Underestimating the problem ([was something else])

[Phil Shafer <[e-mail]>]

Andy Bierman writes:
>We will never have standard writable knobs until vendors understand
>the concept of a standard, and make an effort to define some
>standard knobs, which actually provide enough functionality
>to configure the device.

If you are looking for a constant historical line of thought that
explains the failure of standardized configuration, look no further
than this line above.  The "it's the vendor's fault" line has been
a constant albatross around such efforts.  We are better off admitting
that the problem is not simple, and studying the factors that make
it difficult.  Configuration is not simple and underestimating the
problem won't help standardization issues.

In designing configuration for a complex device, you have a
number of goals:

(a) avoid human error -- design the config to make errors
    detectable in software, and observable in "show" output.
(b) be flexible -- customer deployment scenarios exceed your
    vision when you design something.  Allowing for these
    cases is both important and painful.
(c) complexity reduction -- if it's complex to configure, it
    won't get deployed.  And if it does get deployed, the
    support costs for both the customer and the vendor will
    be high.
(d) details should be hidden where possible -- the user shouldn't
    need to fully grok hardware, software, or protocol issues to
    config them.
(e) enhancement/future proofing -- this config needs to work on
    next year's hardware running next year's software, often
    running next year's protocols.
(f) full feature support -- the config needs to fully represent
    the available features your hardware and software support.
(g) got to be consistent -- make it fit inside the rules and
    conventions of your existing syntax
(h) holistic view -- the config should look like a single description
    of a complete system, not a dog's breakfast of tokens.
(i) I'm sure there's more.....

In the fight for simplification, many of these goals cut against
each other.  For example, in trying to be flexible, I have to decide
when an odd configuration is an error and when the user is just
doing something clever (which may be an error, but is an intentional
one).

For standardization, the goals are often completely different.
Expressiveness and accuracy win over simplicity.  A single complex
method of configuration wins over a dual "common" and "advanced"
approach.  The model for a standard must be something that can
support all platforms, which leads to complexity, and the translation
between the standard's complex model and the unique abilities of
individual platforms is non-trivial.

An example is packet filtering, where the device config is more
often dictated by the hardware architecture and the layout of that
hardware (in terms of where packets can be filtered, what can be
filtered on, what can be done to them at that layer, and what
resources are consumed) is often directly visible in the configuration
in order for the customer to express their desired setup.

But a standard needs an "uber" model, where any sort of filtering
can be done at any place with any outcome without concern for
resource impact.  No vendor will implement this model, and the
translation between the model and the device config requires a
strong understanding of the performance .vs. resource utilization
tradeoffs that the customer is willing to make.

For example, some functionality may be available in hardware at
wire rate; other in hardware at lower speed; other in dedicated
CPUs; and still other in the main CPU.  Choosing the proper filtering
point is a matter of both the speed and abilities of that point,
plus chip memory and other contention issues.  And getting a correct
assignment will still be wrong if it's not the assignment the
customer wanted.

This translation must be performed in a way that avoids letting
small changes in the config from turning into large config changes
on the device.  It's not an easy problem, and to my mind it's the
key to device- independent configuration.

The fact that my bgp configuration doesn't look like the bgp
mib shouldn't be surprising, since the two configurations
serve two different masters.  The lack of any automated
translation between the two is the real killer.

A key aspect of this translation is the ability to round-trip,
turning MIBs into device config and back in a way that doesn't
lose information.

The problem isn't getting a few knobs to configure basic functionality,
but getting a solution that's complete enough to give folks sufficient
faith to move toward it.  If it solved 20% of the problem, it's
worthless.  When it solves 80-90% of the problem, it's interesting.

NETCONF gives us the ability to manipulate configuration in XML,
which is a good first step.  YANG gives us the ability to define
that XML in a way that allows extensibility and the expression of
device-specific content, which is a good second step.  The next
step will be a translation framework that allows robust translation
between a standard view and a device specific view.

So I think we are on the right road, although the pace of the journey
is disheartening.  But regressing to this "it's the vendor's fault"
line is completely unproductive.

Thanks,
 Phil


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