[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SNMP improvements
For me the biggest drag on SMIng and EOS is/was SNMPv2/3.
Like, I just don't see them. Loads of SNMPv1, for monitoring and
alerts as you say, but no use of v2/3 in the enterprises I work in. I
go to the major UK networking trade fair and zilch, the salesmen of
the leading brands of network management tools have not even heard of
differing versions; I leave questions with them, they promise to get
back to me and zilch. (By contrast, a few years ago, that networking
fair was dominated by RMON - every product from hub to server seemed
keen to claim implementation and conformance, the salesmen even knew
the RFC number).
So I see this massive roadblock called v2/3. There were obvious needs
to be met in 1993, for bulk data and security, and in 2003, they are
not yet met, either in theory as in RFC or in practice as in products.
The solutions in v3 would have been good in 1993 but are inadequate
for 2003; the needs have moved on, eg to sparse retrieval of tables.
In 2003 SNMPv3 is (yet again) available as final(?) RFCs and I see
that as the start of a year or two or three while the industry does or
does not decide to implement it. And only after that period can we
realistically do anything about the problems of 2003, problems which
SMIng and EOS might have addressed.
Yup, I am pessimistic (and while netconf may have a better 'SMI' and
protocol, yet I think its requirements are seriously flawed as in eg
the current discussion of multiple configurations)
From: Wes Hardaker <firstname.lastname@example.org>
To: Wes Hardaker <email@example.com>
Cc: Wijnen, Bert (Bert) <firstname.lastname@example.org>; 'Harrington, David'
<email@example.com>; Eduardo Cardona <e.cardona@CableLabs.com>;
Date: 18 September 2003 15:09
Subject: Re: SNMP improvements
>>>>>> On Thu, 18 Sep 2003 10:11:59 +0200, Juergen Schoenwaelder
>Juergen> I disagree, however, that the ADs are a cause for all this -
>Juergen> the problem is that the NM people did after many years still
>Juergen> have not deliver a technology which addresses the
>Juergen> requirements of the operators. Rather than pointing to the
>Juergen> ADs, we should point to ourselves.
>Sorry if I mislead you (and rereading what I wrote it does look like
>targeted them). I think most people failed, from vendors to users to
>ADs to me. We need a roadmap agreed upon by everyone during this
>transition time and we don't have one. I've even offered to get one
>started, and suggested a group it should go forward through but found
>no interest from people even in that.
>So, I kept typing but deleted a few sentences that just sounded too
>depressing. Let's turn it around instead. What *can* we do to turn
>the situation around. That would be better (constructive) use of our
>time. Hopefully netconf will help the configuration side, but we're
>still left with many problems that netconf won't solve as it's out of
>scope. Anyone have thoughts on what needs to be done and how to get
>there? (I'll offer some starting suggestions if no one else does).
>"In the bathtub of history the truth is harder to hold than the soap,
> and much more difficult to find." -- Terry Pratchett