Referring to the issue "Referential integrity across reboots", I have a suggestion.
One way to achieve Referential integrity for ifIndex is to design a formula to calculate the ifIndex, so that the ifIndex used to refer/access a particular persistent data remain the same across reboots (before and after a reboot).
For example; we can design a consistent formula to calculate ifIndex, something as follows;
Let us consider an equipment having the entities, rack, shelves, slots, cards, ports. Let us assume, maximum number of SNMP interfaces (ex; ATM interface, ADSL line interface, ADSL channel interface) supported per slot is X. Then, we can device a formula to find out ifIndex of an Interface uniquely as follows;
ifIndex=<rack #> <shelf #> <slot #> <interface # within the slot. 0 to X>
With this formula, one get same ifIndex all the time for a particular Interface.
Comments are welcome.
Thanks and rgds, Murthy
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Tue, 06 Aug 2002 02:25:22 -0700
>To: "Wijnen, Bert (Bert)" <firstname.lastname@example.org>
>From: Andy Bierman <email@example.com>
>Subject: RE: Referential integrity across reboots
>Cc: "David T. Perkins" <firstname.lastname@example.org>, email@example.com
>X-Spam-Status: No, hits=-2.3 required=5.0
>At 10:54 AM 8/6/2002 +0200, Wijnen, Bert (Bert) wrote:
> >> yes -- I agree 100%. Experience has demonstrated that the ifIndex
> >> and entPhysicalIndex type of MIB design is flawed. (This is
> >> yet another reason why CLI much more useful than MIBs for
> >> configuration.) It is critical that persistent resources retain
> >> the same identity across reboots. I guess the IF-MIB, Entity MIB,
> >> and any other similarly flawed MIB should be fixed.
> >- The entmib WG is currently working on a revision of the entity MIB.
> > May I assume you will pick it up there and come with proposals
> > on how to fix it?
> >- What proposals (if any) do we have for the IF-MIB.
> > And if we have some, can we revive the IFMIB WG (It does
> > still exist as far as I know) to get it fixed there as well.
>Others will quickly point out that it is illegal (by SMIv2 rules)
>to change the semantics/implementation requirements of ifIndex.
>However the only practical (i.e. usable in the real world) solution
>is to do exactly that. There are so many OID pointers and
>subordinate tables that use ifIndex, that it will be pointless
>to create a new ifTable with a new index.
> >- Who is willing to work (I know thet Juergen once started)
> > on a replacement for StorageType that WILL be implementable
> > on most systems and that WILL be usable and workable.,
>I would participate in the WG, especially if Juergen volunteered
>to be the Editor.
-- Murthy.N.N Local: 7-7927 (NC0. Column Q2-12) ESN: 6-357-7927 External: 1-919-997-7927 (Office) 1-919-484-1878 (x 7543) (Res)
begin:vcard n:;Murthy.N.N tel;work:00- 919-997-7927 (8 AM - 6PM EST) x-mozilla-html:FALSE org:Wipro Technologies, Bangalore, INDIA version:2.1 email;internet:firstname.lastname@example.org title:Systems Manager adr;quoted-printable:;;Current address=3B=0D=0ANortel Network,=0D=0A35 Davis drive, =0D=0ADurham 27709 =0D=0ANorth Carolina;;;; x-mozilla-cpt:;-23328 fn:Murthy.N.N end:vcard