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

[Balazs Lengyel <[e-mail]>]

Hello,
This is a VERY good mail about configuration management goals, thank you. I would like to add 
one point:

- in my experience if the configuration is complex, the operator will make big mistakes in it, 
leading to system outage. So if it is too complex it is faulty even if it works.

An operator (organization) can easily have 50 different types of nodes to handle, which might 
mean 2 completely different types per operator (person). For this reason he will often  not be 
an expert in my specific node. According to a telecom industry survey about 50% of node 
downtime is attributable to operator errors. The node is too complex, so they make mistakes. 
And when I say too complex I am not just thinking about operators like Sprint or Uunet, but 
operators in Uganda and Laos.

Balazs

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.
> 
> 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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: [phone]
Tel: [phone]     email: [e-mail]


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