Bob, Bob Natale wrote:
At 9/21/2002:08:00 AM, Wijnen, Bert (Bert) wrote: Hi Bert, I'll take your request for feedback on this specific issue as an opportunity to offer some general feedback as well: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 clients.
I would agree that depending on the specific application and the agent capabilities one should chose to use Inform or gets. 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.
Cheers,
BobN
Glenn M Keeni