[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf FW: November Milestones
Folks, an interesting string. Bert wrote:
> So when we ask real operators as to if they do use SNMP to configure or
> not, then I think we should at the same time ask WHY they do or do not
> do that.
> What is the alternative? A bunch of inconsistent and non-interoperable
> CLI interfaces????
Regardless of the real and imagined reasons by all parties involved; few
major network equipment vendors allow configuration with anything other
than via flat files and CLI commands. If one accepts this point, asking
if/who uses SNMP configuration in a backbone environment is at best
Good and not so good reasons exist for this. The non or under
specification of standards for configuration is a key factor. SNMPCONF
should help since as a result of this WGs activity, people will better
know how to write configuration objects at all levels of abstraction, a
Standard MIB Objects are only part of the issue. The lack of demand by
customers for any configuration alternatives is another factor. Until
now, the major issues for purchasing have been, cost per port/bit, HVAC,
density, and other physical characteristics along with: does your BGP
interoperate with Cisco, and does it scale?
Even without the SNMPCONF work, some of the newer players, especially
those providing edge technology have fuller instrumentation (including
SNMP Config). 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.
One can debate (and we sure have:-)) a variety of alternatives for
improving configuration technology. I think arguments for maintenance of
the status quo would be hard to make convincingly. When 'collecting'
input about what operators want, other than coexistence with what they
have, what I try to find out are things like: How fast do they need to
cause a configuration change, how much computing resource are they
willing to pay for to make the change, how willing are they to ask the
vendors for this, and what types of operational problems (other than
scare human resources) do they have such as fault isolation time,
coordinated configuration changes, etc? I think SNMPCONF will help in
many of these areas.
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