[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Referential integrity across reboots

Dear all,

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-Sender: abierman@fedex.cisco.com
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Tue, 06 Aug 2002 02:25:22 -0700
>To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
>From: Andy Bierman <abierman@cisco.com>
>Subject: RE: Referential integrity across reboots
>Cc: "David T. Perkins" <dperkins@dsperkins.com>, mibs@ops.ietf.org
>X-Spam-Status: No, hits=-2.3 required=5.0
>         version=2.31
>Sender: owner-mibs@ops.ietf.org
>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.
> >>
> >So...
> >- 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.
> >Bert


Local:          7-7927 (NC0. Column Q2-12)
ESN:            6-357-7927
External:       1-919-997-7927 (Office)
                1-919-484-1878 (x 7543) (Res)
tel;work:00- 919-997-7927 (8 AM - 6PM EST)
org:Wipro Technologies, Bangalore, INDIA
title:Systems Manager
adr;quoted-printable:;;Current address=3B=0D=0ANortel Network,=0D=0A35 Davis drive, =0D=0ADurham 27709 =0D=0ANorth Carolina;;;;