Re: Future

[Andrew Bierman <[e-mail]>]

There are two pieces to the Repeater ID problem (or the Bridge ID problem--same thing)

1) A simple to use, universally implementable, method to identify a given repeater.

2) A way to correlate the (now uniquely identified) repeater with a physical location.

Item 1 was almost solved--until the WG removed the repeater ID component from all the
repeater MIB tables. Now community string or party ID or some other proprietary method
has to be used to identify a repeater.

Item 2 would still be a problem even if the WG had left in the repeater ID. Knowing
that you are talking about "repeater 472" is more useful if you know where that repeater is...
The chassis MIB would provide a physical inventory of all devices (including repeaters)
and could also provide the community string, party ID, etc. used to address the device
in the repeater MIB.

Port-switchable hubs and other similar devices make the problem a little more tricky.
You have to identify all possible repeaters (100's or 1000's of repeaters) statically.
As ports are switched, some repeaters may come into existence and others may dissappear.
The chassis MIB would have to handle this type of hub.

--andy;

> 
> I'm curious how the chassis MIB can "fix the repeater ID problem" ?
> 
> Or better yet, I want to be able to fix the problem where I have
> an agent representing 100's of repeaters, so that the user does
> not have to go through configuration hell to retrieve that
> information.
> 
> Same issue for bridges.
> 
> I wonder what would be the right approach to solve this.
> 
> -- Steve

> > > Well another IETF is comming up on us.  I guess I would like to find
> > > out if there is interest in getting together to discuss where we are
> > > going with the chassis MIB.
> > > ...
> > > /David Arneson [[e-mail]] [ [phone] ]
> > > 
> > I'm interested in a chassis MIB that provides:
> >    1) a good definition of a chassis
> >    2) an inventory of physical components in a chassis
> >    3) a fix for the "Repeater ID" problem
> >    4) an indication of the SNMP capabilities of each component 
> >       (i.e. pointers to MIBs, other agents in the chassis)
> >    5) a physical sub-component hierarchy
> > 
> > I hope you can get a BOF scheduled soon...
> > 
> > --andy;
> > 
>