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

Re: Fwd: Re: Review of draft-ietf-snmpconf-bcp-07

>Subject: Re: Review of draft-ietf-snmpconf-bcp-07
>Date: Mon, 14 Jan 2002 09:06:13 -0500
>From: John Schnizlein <jschnizl@cisco.com>
>To: snmpconf@snmp.com
>Questioning the appropriateness of describing configuration through
>SNMP as Best Current Practice will not go away. The most basic reason
>for this is that it is not a current practice.

If you've been dealing only on core/distribution router networks 
and the gear that serve that market I'd agree. However, the reality is 
that snmp is used for configuration at the access/edge of
service provider and enterprise networks. 

>What are the "at least 4 implementations of systems that use SNMP as
>a configuration method" mentioned in your reply below?
>Maybe we missed them.

Indeed. I can give you four different
types of devices that configure primarily through SNMP. 

1) All DOCSIS cable modem systems are configured using 
SNMP directly or using it to control tftp download of config. 
Cable Modem manufactuerers:

CMTS systems including those built by ciscoSystems, 
must have a complete set of standard read-write objects 
which are lightly verified.

2) All ATM Switches. Customers like IXC, RBOC, PTT use SNMP to configure 
most every ATM switch I know of (Fore, Lucent, and even stratacom
at one point a while back). Problem here was that they all 
use private MIB modules and not the ones defined in ATM/ATM2 
MIBs so no standard applications can be written much less
sustain a software company. 

3) Every IEEE transparent bridge w/mgmt support. hp, 3com, cisco, extreme, 
foundry, riverstone, etc. IEEE continues to get it right compared 
IETF protocols in terms of defining in the base
protocol the set of common management operations one might
need. More than one greenfield service provider (esp metro ones) 
have built mgmt systems that can control 1493, 2674 
compliant networks. Has the same problem as #2 but as severe. Lack
of testing does make some concerns about implementation and 
proprietary mib objects are still needed to do things standards
refuses to support but all vendors gear has. (like: turn off stp on a per 
port basis).

4) Many sundry devices have SNMP support.
Just pick up a current copy of Network Computing and look at the 
  a) UPS systems (American Power Conversion, others)
  b) Intelligent Power strips (can't remember the name)
  c) Environmental monitors (netbotz)
  d) Apple Airport (completely not standard use of SNMP though)

Thus SNMP is used for configuration if: 

1) Customers are willing to pay the higher cost (relative to a proprietary cli)
   to build it and get as many bugs out of the implementation as the customer
   needs. (What Andy Bierman keeps reminding everyone)

2) It is a market requirement such that vendors have it forced down their 
   throat as the DOCSIS organization does.

3) Your base protocol/device had the management plane sufficiently thought 
   through in the first place.  If the thing one is configuring is 
   relatively simple and doesn't cause reachablity problems in the rest
   of the Internet if you misconfigure it, then the implementation bugs 
   that might be in an SNMP implementation don't hide the underlying bugs in 
   the protocol/device. (what I call shooting the messenger or simply 
   a complexity tradeoff). 

Mike MacFaden