[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for censensus on path forward



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