[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Call for censensus on path forward
Bob Natale wrote:
At 9/21/2002:08:00 AM, Wijnen, Bert (Bert) wrote:
I'll take your request for feedback on this specific
issue as an opportunity to offer some general feedback
I would really like to hear from a few operators (or
even NM application developers) if they indeed find it
a requirement to do polling a 1-second-granularty.
It does not sound realistic to me... but who is me?
1. If a management application requires sub-second
data updates, a publish/subscribe model should be used.
For SNMP, the Inform-PDU can perform this role for a
large set of application scenarios. Of course, that
implies MIBs (and agents which implement them) which
support the necessary registration process for Inform
I would agree that depending on the specific application
and the agent capabilities one should chose to use Inform
Yet, whether it is an "inform" or a "get" the problem does
not change very much. The overhead of the OIDs remains
exactly the same. Aggregation helps in both cases.
2. Of the current proposals under discussion, the only
ones that I could support are the "Extended Capabilities
Negotiation" the "Aggregate MIB"...approaches that do not
modify the underlying protocol. However, both of them
need to be modified for use in an AgentX extensible
environment. And I don't really see the absolute need
for either of those proposals to achieve what I think
are necessary goals for SNMP at this time.
I totally agree here. And I believe that this eminently doable.
3. That last comment leads me to my major point: I am
not especially enthusiastic about any of these proposals.
My summary view is that we need more capable MIBs -- and
agents which implement them, of course. The trend in
large-scale service provider network management technology
today is toward more "bottom-up" capabilities via NE software.
Coupled with increased security requirements for that same
software, the renewed (it's a cyclical thing, you know)
focus on bottom-up, presents an opportunity for resurgence
of SNMP. Protocol stability -- at v3 -- coupled with
more capable MIBs and agents -- is a fundamental requirement
at this stage.
I agree that we need more powerful MIBs and their deployment.
The Aggregate MIB is an aid to handling MOs in present MIBs in
an efficient manner, where routine polling is involved.
4. Three final asides:
a. I draw the above observations from detailed
familiarity with a number of major service
provider procurements currently underway.
b. At the risk of showing my age, I believe that
MIBs can be made *vastly* more capable -- in
terms of, e.g., aggregate/derived objects,
behavior/operations, secure sets, multi-entity
interoperation, publish/subscribe services, etc.
-- without major mods to the SMI and definitely
without modifications to SNMP[v3] itself.
I am a MIB believer too :-) We have developed SNMP-MIB based
solutions for a range of applications - from Network Security
systems to Automobile systems (for the Internet Car project ).
I would like to certainly hear more about that.
c. The primary role of management applications in
the new paradigm will be to translate user policy
configurations into agent (MIB) configurations,
let the agent do its work, and inform the user
of operational exceptions relative to the behavior
stipulated by the policy.
Glenn M Keeni