Re: Interface Table

["David L. Arneson ([e-mail])" <[e-mail]>]

 
> Technical
> 
>     1.	It should not be called an "interface" table.  That
term means MIB-II
> 	interfaces, identified by an ifIndex.  I'm not sure what the right
> 	word is, perhaps port.
>
It seems to be a connection table perhaps something more along those lines.
 
>     2.	As specified, chasIfIndex isn't necessarily unique.  My
understanding
> 	is that a repeater, for example could have an interface number 1 and
> 	a repeater port number 1 that are not related and could conceivably
> 	have different segment mappings.  To be unique, it will have to be
> 	qualified by type.
> 
>     3.	The type bitmap is completely opaque to a generic network management
> 	system, but is absolutely necessary to find further information at the
> 	entity.  I believe an OID as Keith suggested is far more appropriate
> 	here.
>
I guess I wasn't thinking to clearly at that time.  In view of the above
I should back up to my original stance.  This type of index is useful but it
can not exist in this table.  The bit map was chosen since an interface may be
used for multiple uses.

I guess we don't really need the type since we have entity in this table.
Given entity we can reference the entity table adn get the type from there.
 
>     4.	It seems to me the index order should be entity, port,
segment, since
> 	the port information is dependent on the entity.  I would expect to
> 	look up a mapping that way, answering the question, "What the heck
> 	segment is that stupid repeater port mapped to?"
>
Valid point, the interface would normally vary most frequent.
 
>     5.  If slot is to be included, it seems more appropriate as the first
> 	index, as in the configuration table, or perhaps it's redundant.
>
I belive that we need slot information here.  We may infact have an entity
that is split over multiple modules.  The slot provides us with what's connected
where.
 
> Philosophical
> 
> This information is complex and implementation dependent.  It will have to be
> available from each entity's own MIB, where it can also be controlled, and is
> therefore redundant.  Given that I must go to the entity's own MIB, how does
> having it here help me?  In that entity's MIB it can be expressed in
> appropriate terms.  In this MIB we must use the union of all potential types
> of mappings, thus making the presentation more complex.
> 
> Although various people say they want or need this, no one has responded that
> their implementation can provide it.
>
The way I have always read "need" is that we must find a way to make it work.
I agree it is not an easy table to implement.  However if you need to present
this information then you must find a way to implement it. 

Yes much of the information in this table can be found else where.  However
the information is not redundant in that it still provides a connection to
slots.  I feel the table fills a large hole around physical mapping
of the segments in the chassis.  This information is not easy to gather
by using the entities specific mibs.

> Making things optional instead of making hard choices does not make good MIBs.
> 
> The Chassis MIB is not supposed to be the answer to single point of control
> network management.  Let's keep information properly distributed.
>
Optional was chosen because I agree that some vendors have no need for this
table.
 
> If we must define a standard for detailed segment mapping, we should define it
> for use in the context of the individual entities.
> 
> 	Bob
What I really want to implement is a table indexed by segment and interface
that is inside of the entity table.  However a table within a table is not
allowed so we must settle for a connection point to the other table.

Let's put this philosophical qustion aside.  I think the information within
the table defines that the location must be part of the chassis MIB.

I believe that we are in this to satisfy the common good.  So lets let the
working group define if this table is useful and implementable.  I don't
have an axe to grind here.  If the working group says no then I will just
find a way to implement this table on my own.  So there was about 25 of
us in the room at Boston.  Can we conduct a vote via mail?