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

On Jan 16, 2008, at 2:47 PM, Andy Bierman wrote:

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

I think there is a lot of merit in a 'registry-based' mechanism  
approach.   You would still need aspects of what has already been  
accomplished, and YANG, or something else for the broad solution  
desired.
/jon
>
> 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
>

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang