[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf FW: November Milestones

Randy Bush wrote:
> [ operator hat only ]
> > few major network equipment vendors allow configuration with anything
> > other than via flat files and CLI commands.
> in the backbone router market, there are two vendors.  both claim that their
> equipment can be configured using snmp write.  i just don't know anyone who
> has tried it.

Assuming you mean Juniper and Cisco. It is true that Cisco has an object
that you can set that causes it to ask for a file download (Juniper may
also - I just do not know). There are a few (very few) setable
parameters that can be set from either vendor. To claim either of these
is configurable via SNMP falls outside the limits of credibility. 
> > The reason is; CLI's and file transfer will not continue to scale at least
> > at a human level. The economics of the availability of personnel who can
> > manage networks that are controlled with CLI's will be the factor that
> > causes operators to ask for something better. That has not happened until
> > recently.
> to keep apples and apples, how many people can type snmp stuff directly to a
> router?  darned few.  and who cares?

So your point is? SNMP is not intended as a user interface. It is a
method of defining management objects, a protocol for their
transmission, and an administrative framework. Few people can read LSAs
on the wire either. 
> like mibs, the text config files are merely an intermediate representation.
> do not underestimate the value of being able to email snippets of configs,
> cvs them, diff them, ...  there is a vast array of tools which work on text.
> think about having to write a tool to determine the difference between a
> running config and a proposed new config and emailing an easily understood
> representation of the poposed change to a distributed team.

True, that does not mean that intermediate forms have to be the method
of transport (or storage) for the configuration information. Databases
and other systems have done at least as good a job as most text tools do
in determining differences. It is probably easier, and in the long run
less costly since each ISP would not have to reinvent the wheel for all
the text manipulation tools again and modify them all over again each
time a vendor changed file formats or added new parameters. What is also
true is that operational staff people have an investment in what they
know which should not be undervalued. It is also true that investment
makes them less amenable to change which is not in the financial best
interests of the company if one believes that there really is a scarcity
of human resources. More people and hand crafted tools that can parse a
number of different configuration file formats does not seem like the
best solution.

> > Configuration is the heart of management. To the extent MIB Documents
> > are created in each of the different technology areas such as routing or
> > differentiated services (which is the right place), they should be
> > designed for full coverage including configuration. There is no excuse
> > not to.
> i do not intend to discourage those who wish to design for write from doing
> so.  but i am not sure i see a need to mandate it when doing so would cause
> complexity or architectural change.  and i believe that, and only that, was
> the question (in the tewg) that [re]started this rathole.

That is why we have the problem in configuration today where everyone
does it themselves. Put a Cisco and Juniper config file next to each
other and try to parse their meaning if you do not know each of them
intimately. It is harder to write configure configuration code (using
any method) than reading counters. There is a need for a standard that
can expand to accommodate vendor differences. I see this as the
justification for the extra work.