Subject: RE: snmpconf FW: November Milestones

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 3 Dec 2000 12:40:21 +0100

Comments inline

> ----------
> From: 	Randy Bush[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Sunday, December 03, 2000 7:30 AM
> To: 	Dan Romascanu
> Cc: 	[email-masked]'
> Subject: 	Re: snmpconf FW: November Milestones
> 
> > The SNMPCONF WG might be interesting in this message, from one of our
> Area
> > Directors.
> 
> actually, i was saying it as an operator, and in response to a question of
> whether a mib should be designed for config as well as read.  my question
> of
> whether any large operators do puts was really meant at face value.  i
> really want to know if any large providers enable and use write.
> 
I think MIBs should be designed for both monitoring AND configuration.
If some vendors want to implemement just monitoring, then we can
allow for that in a compliant way by specifying two sets of MODULE
COMPLIANCE statements, one for read only and one for the full
support including config.

I also understand that up till now, a lot of operators have not used SNMP
(v1 or v2c) because of security concerns. And in fact, some MIB designers
have taken the read-only path as well, again because there was
no security in SNMPv1/v2c.

Therefore, I assume/hope that SNMPv3 will be exploited so that we can
start to take a serious look to using SNMP for configuration
management.

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

Bert

> randy

---

From: Jon Saperia <[email-masked]>
Date: Sun, 03 Dec 2000 13:34:57 -0500

> What is the alternative? A bunch of inconsistent and non-interoperable

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

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

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

/jon

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Dec 2000 11:24:27 -0800

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

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

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.

> designed for full coverage including configuration. There is no excuse

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.

randy

---

From: Jon Saperia <[email-masked]>
Date: Sun, 03 Dec 2000 15:42:20 -0500

> equipment can be configured using snmp write.  i just don't know anyone who

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

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

/jon

---

From: Andrew Smith <[email-masked]>
Date: Sun, 03 Dec 2000 21:07:31 -0800

From a thread from the snmpconf WG:
 > Jon wrote:
 > the question (in the tewg) that [re]started this rathole.

Randy's point is well made - I don't think it is a rathole - and is directly 
relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In 
the various iterations of the diffserv MIB we have veered between extremes of 
optimise-for-read and optimise-for-configure without, I think, a clear idea of 
why. The -04 version tended towards the former whilst the latest incarnation 
(-06) veers back towards the latter in the interests of consistency with the PIB 
work and the "template" concept for the diffserv policy MIB (snmpconf WG). 
Should we treat these as valid reasons to sacrifice read performance or should 
we find another way to optimise opbjects for configuration e.g. by duplication 
(indexing of same information in multiple ways)? Right now, I believe the -06 
MIB does cause additional complexity for reading.

Andrew

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Dec 2000 21:21:06 -0800

[ operator hat only ]

we do a LOT of reads, so many that we have to gang boxes to do them, and
write tools to manage the poller array.

if we were to do snmp config, i presume it would be FAR fewer operations
than the polls and other gets.

randy

---

From: Jon Saperia <[email-masked]>
Date: Mon, 04 Dec 2000 08:46:21 -0500

> MIB does cause additional complexity for reading.

It is often the case that read only MIB documents are not well designed
in a number of respects. Relevant to this discussion is that the indices
are often created with implementation ease in mind. It is more difficult
to implement a table with multiple indices (regardless of basic
technology) than to use simple integer index values. This is true
whether the objects are read only or read write.  This poor design,
while easy for software engineers, causes unnecessary data collection
overhead since it is more difficult to 'scope' what you want to retrieve
(Randy indirectly alluded to this in a previous post). In some cases,
the design makes it quite difficult not mater how much data you collect
to understand what it means in terms of the configuration.

My view is that the additional complexity for configuration will pay off
in terms of better quality data and less data movement. This is not to
say -06 is just right, there are other who can  better assess that. My
point is that it is worth the work.

/jon

---

From: "Andrea Westerinen" <[email-masked]>
Date: Sun, 10 Dec 2000 20:52:06 -0800

Some of the info modeling work may be pertinent here.  Some of the models
separate state and current operational data from configuration information.
The latter is described by Setting classes and collected into Configuration
aggregations.  You can send clearly defined Setting classes and instances to
a device.  You can "apply" these Settings to a device and/or its components.
You can retrieve (read mostly) current state/operational data from other
classes and instances.

Just FYI...

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Jon Saperia
Sent: Monday, December 04, 2000 5:46 AM
To: [email-masked]
Cc: diffserv; Randy Bush
Subject: Re: snmpconf FW: November Milestones

/jon