RE: MALLOC MIB

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