Re: snmpv2 Will it flood us or be slow

["Robert D. Graham" <[e-mail]>]

 Previous comment by Karl Auerbach:
 >My view of V2 is that it is more like the Social Security
 >Administration -- an administrative nightmare that has far more
 >administrative framework that is reasonable to do a simple job.

I've been working with some SNMPv2 implementations. I do agree
with Karl that in order to take adavantage of Authentication/Privacy, you
have to go through an enormous amount of manual configuration.

Personally, I am "rabidly" against manual intervention in networks. I
believe it is a bad, bad, bad idea. I have this funny opinion that
computers (and networks) should be servicing us human beings, and
not the other way around.

That is a bit of a condescending statement; I only state it because TCP/IP
requires an "abnormal" amount of manual configuration when compared against
other popular networking alternatives (Novell, AppleTalk, NetBEUI,
AppleTalk, SNA/APPN, Banyan Vines). Sure, it has more power than these
other networking suites, but that power isn't related to this abnormality.

Let me put it another way: I can "prove" that the main limitation to
Internet growth is this abnormal requirement of manual configuration, not
address size or routing table explosion.

The proof goes something like this:

1) People will generally agree that we can solve address space/routing table
   problems in the NEAR TERM if we simply reassign all the addresses on
   the Internet along CIDR guidelines.
2) CIDR's main problem in the LONG TERM is entropy. We can solve that
   problem by reassigning all the addresses on the Internet
   every few years. With regular reassignments, this should allow
   TCP/IP to service the Internet up to around 500 million nodes.
3) The comments (1) and (2) are absurd given the enormous cost of
   reassigning the IP address of all nodes attached to the Internet.

However:
   If TCP/IP required as much manual configuration (or reconfiguration)
   as those other protocol suites, we would only need to reconfigure
   all the IP routers, and not workstations, servers,
   or DNS servers. This still would be difficult, but not outside the
   realm of reasonable costs. In fact, I think that most individual
   organizations wouldn't mind at all reconfiguring their routers once
   a year.

   In other words, the average (among all protocol suites) manual
   configuration of a device is a NAME. However, the average manual
   configuration of a TCP/IP machine is a name/IP address in a DNS
   server, an IP address, a mask, local gateway(s), broadcast address,
   etc, all of which would have to be reconfigured if the network
   addressing changed. These other protocol suites are based around
   the assumption that the network address of ALL devices will be
   different every time they are rebooted, so the only way to
   reach any device is through a name.


   Thus, we could solve the Internet's most pressing problems if we
   could simply redo the IP addressing, and we can't do that because
   of the ABNORMAL amount of human servicing required by IP.


I agree with Karl. SNMPv2 requires too much human servicing. In fact, 
SNMPv2 claims to be able to run over many transports, but I don't know
how authentication will work for AppleTalk, because you can't reliably
configure AppleTalk addresses in the authentication files (the first
step in authentication is to check the network address of the incoming
packet against the party's network address). Anybody know how this 
works for AppleTalk???

There is no reason why SNMPv2 couldn't be patched to solve this problem.
For example, we could probably define a "CommunityIP" Transport Domain
that would ignore IP addresses and essentially work the same way
as SNMPv1 community names. We could phrase this change in such a 
way that it would still fit within the SNMPv2 framework. This would 
relieve most of the manual configuration problems.


Rob.


PS: Less manual intervention means more robustness. Duplicate addresses
    in AppleTalk, Bines, NetBEUI, NetWare, etc. are almost unheard of,
    but is a constant problem with IP networks. Other networks similarly
    have fewer problems with routing loops and broadcast storms.