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-m=
ib-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=20
> un-justified multiplication of the number of rows? We should be
> careful here. The ifStack like models have little deployment=20
> today, and the concern about the multiplication of the number=20
> of entries in devices with multiple overlayed interfaces may=20
> be related. What is the opertional benefit from having a=20
> 'nonexistant' enumerated value defined?

Anything that manages a large number of interfaces (such as=20
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.=20

The current ifStackTable and ifInvStackTable have entries=20
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=3Dactive
       ifInvStackStatus.0.z=3Dactive

    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=20
> "can connect" table would track that two interfaces cannot
> physically be connected, which seems kinda pointless. =20

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

--=20
Bob Ray <[email protected]>