Re: MALLOC MIB

Steve Hanna <[email protected]> Fri, 17 May 2002 09:19:51 -0400
Newsgroups gmane.ietf.malloc
Message-ID <[email protected]>
Yes, I guess you could always define a MIB or other management
technique to go along with any mechanism for coordinating
multiple MAAS's.

OK, I'm convinced. I agree that you should remove the exclusion
table from the MIB.

-Steve

Dave Thaler wrote:
> 
> Steve Hanna wrote:
> > If people use some protocol or technique to coordinate the
> > efforts of several MAAS's allocating from a single address
> > range, each MAAS will need to exclude addresses allocated
> > by the other MAAS's (and maybe some addresses reserved for
> > future allocations by the other MAAS's).
> >
> > This could be done by dividing each allocation range into
> > several allocation ranges and ensuring that each MAAS only
> > knows about one of these. But this will prevent the ability
> > for a MAAS to report (via the Allocation Range Table) on
> > the overall status of an allocation range: how full is
> > scope X? and are requests being met? Instead, the status
> > will be fragmented into separate allocation ranges for
> > each MAAS. If the MAAS's aren't communicating, then this is
> > probably the best thing to do.
> 
> Agree.
> 
> > But if they are communicating
> > (through a directory, an experimental protocol, or whatever),
> > then I think we want to retain the ability for a MAAS to say
> > "I'm allocating out of this range, but excluding these
> > subranges."
> 
> The semantics of the existing AllocRange table (and counters)
> are currently specific to a single MAAS.
> So ranges listed are ranges in which the device is itself
> allocating from.
> Without the exclusion table, a MAAS can say
> "I'm allocating out of this scope, but excluding all subranges
> that aren't in the AllocRange table."
> which sounds pretty close to what you said except that
> it does not report the overall status of an allocation range.
> 
> > So I think we should leave the Exclusion table in the MIB.
> > People who don't use it can always leave it empty. I welcome
> > any further discussion, though.
> 
> The argument for removing it is that without an experimental/
> proprietary protocol, there is no use for the exclusion table.
> With an experimental/proprietary method, you already have
> experimental/proprietary stuff so it seems reasonable to
> get "overall status" the same way.  (E.g. from a directory
> you mention, or from a MIB specific to the experimental
> protocol, or whatever).
> 
> Hence, I'd still like to remove it.
> Do you have a strong objection to doing this?
> 
> -Dave