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

Re: Proposal cutoff deadline September 15



Hi,
As Andy has pointed out the three proposals are addresing different
problems and propose specific solutions. So it is not really a matter
of chosing one solution from the three on the table.

There is a overlap in functionality between the AggrMIB and the OOPs
proposal. In the following I will try to bring out the differences
between and the utility of the two approaches. (Wes will correct me
if I have misunderstood any part of his proposal)

1. The features:
================
   a. Both fetch values of several objects at one go (In one PDU).
   b. Both attempt to reduce the bandwidth overhead of the ObjectNames

2. The approaches:
==================
   a. OOPs specifies the set of MOs on the fly in the form of filters.
      AggrMIB goes through an initialization phase where the set of MO
      instances are each explicitly specified to the agent.
   b. OOPs achieves reduction in the overhead of the ObjectNames by using
      a base OID and giving the indices as "indexData" in an "ObjectDataList".
      AggrMIB achieves reduction in the overhead of the ObjectName by
      using a single (newly defined) ObjectName.

The applicability:
==================

   a. The AggrMIB has a one-time overhead for "Programming the AggrMIB"
      on the agent i.e. defining its own set of MOs of interest. Naturally,
      the AggrMIB approach will NOT be suitable if it is a one time browsing
      operation.
      [Probably this is what Andy doesn't like. Pre-configuration by itself
      is not new to us. We have been doing it for some time in several MIBs
      expression-MIB, script-MIB, RMON-MIB]
      But AggrMIB will work very nicely if the "MOs of interest" are fetched
      repetitively (routine polling !). This is what I like :-)

      OOPs does not require any overhead like sets etc. to specify the
      "MOs of interest". No "preconfiguration". This is done on the fly -
      the MOs of interest are specified in in terms of a filter. (The SMALL
      operational/bandwidth overhead is in every PDU.)

   b. The name-overhead reduction in OOPs works well when the MOs are related
      in some manner and if the indices are small.
      [Two cases to note:
       o There may be cases where multiple MO instances from multiple tables
         are referred to.
       o Indices themselves are not small (cf.  tcpconn table, routing table,
         ... ). ]

So how does it look? I think that the two mechanisms complement each other.

a. an application would use OOPs when doing "gets" of a set of objects
    in a table, (even if the instance identifiers are not known a-priori).
b. an application would use AggrMIB when it knows what it needs, and when
    it needs it repetitively.
c. some SNMP-development kit will have an API that accepts a set
    of MO-instances in terms of a filter, uses the OOPs to fetch the
    corresponding object instances, does the requisite sets to configure an
    AggrMO instance and returns the AggrMO to the application for subsequent
    use.
d. the same application may use different mechanisms depending on the
    circumstances. In one case, an application may chose to fetch several
    MOs from several tables using the OOPs mechanism. In the other case
    the application may find it wiser to define one or more AggrMOs and
    use these. [ Developers will have to choose what they want, get,
    get-next get-bulk, oops, aggrMO, ..]

Applications will have more control on performance. How and when this
control will be exercised will depend on the developer. I see greater
potential for evolution and growth in this direction.

Glenn M Keeni


Andy Bierman wrote:
> At 03:22 PM 9/13/2002 -0400, Glenn Waters wrote:
> 
> 
>>Not that a reminder is necessary, but proposals are due by Monday. 
> 
> 
> We are not just being asked to pick a solution, but rather a
> problem and a solution. These 3 drafts address different problems.
> 
> I would like to see the WG focus on solution (2), but
> incorporate the concepts of (1) into the new PDU format.
> I would like to see the problem addressed by (3) solved
> with general mechanisms in the protocol, without the
> requirement of any pre-configuration by an application.
> 
> Andy
> 
> 
> 
>>The three proposals currently on the table are: 
>>
>>1. Dave Shield's Extended Capability Negotiation 
>>  www.ietf.org/internet-drafts/draft-shield-eos-capabilities-00.txt 
>>
>>2. Wes Hardaker's Object Oriented PDUs for SNMP 
>>  www.ietf.org/internet-drafts/draft-hardaker-eos-oops-00.txt 
>>  (soon to be -01) 
>>
>>3. Glenn Mansfield Keeni's Managed Object / Aggregation MIB modules 
>>  www.ietf.org/draft-glenn-mo-aggr-mib-01.txt 
>>  www.ietf.org/draft-glenn-mo-taggr-mib-00.txt 
>>
>>The WG needs to come to consensus on path forward from here. 
>>
>>I propose that we select one of the three solutions listed above as the one solution that the WG will focus on for development.
>>
>>The question that I plan on asking on Monday is: 
>>
>>Which of proposals 1, 2, or 3 do you think that the WG should pursue to focus in on the work items in the charter? 
>>
>>Is there any discussion around the question? 
> 
> 
>