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

Phil Shafer wrote:
> 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.
> 

I do not think it is all the vendors fault.
The IETF process, the current state of data modeling tools
used in NE development, and lack of relative priority among all
customer requirements contribute greatly.

(I hope the requirements spec captures all your text below.)

Since we already know that getting 10 vendors together
in a WG meeting room just to agree there is nothing in
common to standardize doesn't work, we need to come
up with a new plan.

IMO, the IETF has been avoiding the real problems facing NETCONF.
YANG does not address the real problems preventing standard
data models for configuration either.

I am hoping that in the end, the solution is something more
elegant than a standard way to figure out which of the 47 ways
a particular device implements a given data model.
But if not, then maybe registry-based-indirection mechanisms
would work instead.

Andy

> 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
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang