FW: RE: available connections thoughts

if-mibers,

This discussion happening in the hubmib wg may benefit from your feedback. The I-D in cause is http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-mib-00.txt.

Thanks and Regards,

Dan



-----Original Message-----
From: Bob Ray [mailto:[email protected]]
Sent: 16 March, 2004 3:32 PM
To: Romascanu, Dan (Dan)
Cc: Menachem Dodge; [email protected]; [email protected]; Mike Sneed
Subject: Re: [Hubmib] RE: available connections thoughts


On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote:
> This is better. However, your proposal lights another warning
> beacon for me. Would not this 'nonexistent' value lead to an 
> un-justified multiplication of the number of rows? We should be
> careful here. The ifStack like models have little deployment 
> today, and the concern about the multiplication of the number 
> of entries in devices with multiple overlayed interfaces may 
> be related. What is the opertional benefit from having a 
> 'nonexistant' enumerated value defined?

Anything that manages a large number of interfaces (such as 
an OC-3/12 to dsl bridge/router), and that is based to some
degree upon the cross product of the ifTable is gonna be huge. 

The current ifStackTable and ifInvStackTable have entries 
for unconnected upper and lower interfaces.  From RFC2864:

   "For example, two rows exist even for an interface which has
    no others stacked on top or below it:

       ifInvStackStatus.z.0=active
       ifInvStackStatus.0.z=active

    This table contains exactly the same number of rows as the
    ifStackTable, but the rows appear in a different order."

I suspect a "nonexistant" enumeration is equivalent to the above.
You may have noted my comment that:

> Note that "nonexistant" implies that the hypothetical 
> "can connect" table would track that two interfaces cannot
> physically be connected, which seems kinda pointless.  

In which I meant, "I see no sense to a nonexistant enumeration".  
Which is why I left it out of the later enumeration. :)

-- 
Bob Ray <[email protected]>