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

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Jan 2002 11:05:17 -0800

>Subject: Re: Review of draft-ietf-snmpconf-bcp-07
>Date: Mon, 14 Jan 2002 09:06:13 -0500
>From: John Schnizlein <[email-masked]>
>To: [email-masked]
>
>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:
http://www.cable-modems.org/gallery/

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 
advertisements: 
  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
www.nmops.org
www.riverstonenet.com

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Jan 2002 11:16:16 -0800

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

by whom?  despite a year of looking, going to meetings on four continents,
talking to enterprises and isps, ... we have not found this to be the case.

as cisco and other do not even implement config via snmp, such broad
statements do not see very supportable.

yes, various edge devices do config via snmp.  and if that is the only means
they provide, that's what folk are forced to use.  but you will find that,
if they have a choice, they use cli, whether we like it or not.  for what
happens in the market, remember cascade.

randy

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Jan 2002 11:56:19 -0800

>talking to enterprises and isps, ... we have not found this to be the case.

If you conducted an actual study in a scientific manner, I'd like to 
see the data before the conclusion. 

The list above does not include the specific customers I mentioned:  
telcos (the atm part, not the isp part), cable modem, 
layer 1/2 metro serivce providers.  Go ask these folks what gear
they use and how the manage it.  

>statements do not see very supportable.

Cisco *does* support snmp config where there is a market requirement 
or is legacy gear that already supports it as in the case of the 
uBR (see Azlina Palmer) or the Catalyst 3k(kalpana)/5k(creshendo) 
transparent bridge product lines (Cal Palmore). 

>if they have a choice, they use cli, whether we like it or not.

I sympathise with your zeal for a smaller simpler to use/create 
management interface. Really I do.

If customers have a choice of mgmt interfaces, they will 
prefer/use any number of interfaces. Over the years I've been asked to 
support in addition to SNMP:
HTTP, JavaBeans, TL1, XML, COPS, LDAP, a GUI craft interface
and configuration through an EMS. 

I then explain the benefits of our product's CLI, such
as cmds are placed into scrachpad and activated at once, 
difference between a active ram configuration and bootup 
configuration, joys of editing acls with an online editor, 
being able to diff and search configs while in config mode, 
authentication with raduius/tacacs+, etc.

Truth be told, Customers will use whatever they understand 
and whatever doesn't crash or impede the device.

Mike MacFaden

---

From: "Jon Saperia <saperia>" <[email-masked]>
Date: Mon, 14 Jan 2002 15:09:53 -0500

On Monday 14 January 2002 02:16 pm, Randy Bush wrote:

> by whom?  despite a year of looking, going to meetings on four
> continents, talking to enterprises and isps, ... we have not found this
> to be the case.

I would like to add to Mikes comments since he started to 'name names'. 
There is of course the RMON set of vendors that include Netscout. There 
are other vendors in this market as well such as HP et. al.. I mention 
Netscout since I have built applications that configure it (and other 
probes) and use the resulting data for network performance analysis. The 
application also configured other RMON devices from other vendors as well. 
Certainly RMON is a widely deployed and used technology. 

A different type of product than RMON or the switch/router vendors are the 
bandwidth manger products. One such example is Sitara Networks. Their 
entire policy for Qos can be provisioned through a number of techniques 
including SNMP. In fact, they have an application called the QosDirector 
that was a best of show finalist and peoples choice award winner not too 
long ago.  This product has been shipping for some time as well though 
RMON is clearly the oldest in this category.

In terms of router types of products, IronBridge Networks provided a 
standard CLI that would be familiar to most people that was based on an 
SNMP infrastructure. It's performance was reasonably comparable to CLI 
only based systems that are the norm in most core environments. 

One of the reasons that you may not have heard about the examples Mike put 
forward or these is that like network operators, many of the people who 
are building products for a living to not spend time on IETF lists of any 
kind. They are busy building product.

With regard to the points about whether this should be a BCP or not we 
have indeed discussed this. In section 5 of RFC2026, I see nothing that 
raises the bar of such documents to include deployment or use. That said, 
The examples I provided above along with Mikes indicate not only 
deployment but actual use.

/jon
-- 
Jon Saperia                         
				
[email-masked]
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/