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