Subject: RE: [midcom] SNMPv3 and multiple MA requirement

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 13 Dec 2002 17:40:18 -0500

Dave:
Thanks!
So the answer is not in SNMPv3 but in SMIv2 and MIBs, or how they work 
together.

Some example with existing MIBs and the operational experience using them in
situations similar to MIDCOM will be very helpful.

The operational complexity will be determined when such exercise is done.
-- Kwok --

At 05:13 PM 12/13/02 -0500, Harrington, David wrote:
>Hi Kwok,
>
>The simple solution to coordinating mutliple managers trying to set 
>information at the same time is to use an advisory lock.
>
>RFC1907:
>snmpSetSerialNo OBJECT-TYPE
>        SYNTAX     TestAndIncr
>        MAX-ACCESS read-write
>        STATUS     current
>        DESCRIPTION
>                "An advisory lock used to allow several cooperating
>                command generator applications to coordinate their
>                use of the SNMP set operation.
>
>                This object is used for coarse-grain coordination.
>                To achieve fine-grain coordination, one or more similar
>                objects might be defined within each MIB group, as
>                appropriate."
>        ::= { snmpSet 1 }
>
>This is very coarse-grained and only advisory, however. Finer-grained 
>control would probably be better in most cases, and mib-specific 
>snmp-agent-enforced locks are more reliable and often simpler. For 
>example, defining the owners of rows, as is done with RMON, can limit who 
>can change which rows within a mib table.
>
>SNMP has one MIB that all MAs use, and it is composed of multiple mib 
>modules. VACM has a complete knowledge of all the SNMP data manageable at 
>the device, and VACM can be utilized to control, based on the 
>administrator's preferences, which MAs have access to read or modify which 
>portions of the MIB - by mib module, by table, and by row as needed. A 
>well-designed mib solution will take access control into consideration.
>
>There are times when one must coordinate multiple values to ensure 
>consistency. Many mibs have been written over the years that have 
>successfully addressed such consistency issues. A well-designed mib module 
>will take data dependencies into consideration, and describe the expected 
>behavior and locking that should be supported.
>
>There are many ways to approach the coordination of multiple management 
>applications, and such methods have been used successfully in SNMP 
>environments for a number of years.
>
>dbh
>
> > -----Original Message-----
> > From: Kwok Ho Chan [mailto:[email-masked]]
> > Sent: Friday, December 13, 2002 3:04 PM
> > To: [email-masked]
> > Cc: Kwok Ho Chan
> > Subject: [midcom] SNMPv3 and multiple MA requirement
> >
> >
> > FYI!
> > If SNMPv3 (and assuming SMIv2 is used also) is used as the
> > MIDCOM protocol,
> > There are additional complexity when considering the usage of
> > multiple Middlebox Agents (MAs) with a Middlebox (MB).
> >
> > 1.  When multiple MAs trying to control the same resource on
> > the MB, SNMPv3
> >       does not allow simple control of which MA performs SETs
> > to which object
> >       instance in which order with deterministic results.
> >       For example resource on MB is controlled by MA-1, MA-2, MA-3
> > concurrently.
> >       Resource is parameterized by object-1, object-2,
> > object-3.  And they are
> >       inter-related.
> >       MA-1 created the object-1 instance needed for the resource.
> >       Object-2 and object-3 must be created correctly before
> > the resource is
> >       setup/allocated correctly.
> >       Before MA-1 can create object-2, MA-2 modifies object-1
> > instance to an
> >       unacceptable value for MA-1 usage of the resource.
> >       MA-1 does not know object-1 instance have been modified by MA-2
> >       and tries to created object-2 instance and succeeds (notice the
> >       successful operation is a problem, it should have failed).
> >
> >       When multiple MAs are used, it is never sure that the
> > previously set
> >       up object instance by an MA is not changed/deleted by
> > another MA.
> >
> >        This may possibly be handled by specifying the detail
> > access control
> >        for each object attributes with dynamic changes of
> > which operation
> >        (read/write/create) by whom at what time.
> >        But this adds much complexity to the SNMPv3 usage.
> >        Are there better ways?
> >
> > 2.  When the same resource (same instance of one or more
> > objects) on the
> >       same MB is being changed/created by multiple MAs at the
> > same time,
> >       how is this handled?
> >       Will a spin-lock be needed for this?  How would this
> > add to complexity?
> >       How can the result be deterministic when each MA is
> > changing the object
> >       instance to a different value?
> >
> > Does these complexity require some additional investigation
> > of HOW WELL the
> > protocol meets the requirements?  And will people use it this
> > way given its
> > complexity?
> > Maybe we need to focus on solving the MIDCOM problem using each of the
> > candidate protocols (may be one at a time or in parallel)
> > before making the
> > firm decision of picking a specific protocol.
> > I think someone have indicated before on this list that the
> > devil is in the
> > details.
> >
> > Thanks!
> > -- Kwok Ho Chan --
> >
> >
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/midcom
> >

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 15 Dec 2002 22:21:29 +0100

Kwok,

A part of your point 1 was alreay answered by the discussion
on atomicity that David and I had. You can set several objects
with a single SNMP packet and have them all set or none of them.
This includes establishing or deleting a pinhole or a NAT binding
atomically.

    Juergen

-- Kwok Ho Chan wrote on 13 December 2002 17:40 -0500:

> Dave:
> Thanks!
> So the answer is not in SNMPv3 but in SMIv2 and MIBs, or how they work together.
>