Subject: Questions on the OSPFv3 MIB : draft-ietf-ospf-ospfv3-mib-10.txt

From: "Goyal, Manoj" <[email-masked]>
Date: Thu, 2 Mar 2006 17:07:30 -0800

Hi,
In the ospfV3 MIB I don't see the ospf instance ID being
used properly as the index.
As per the ospfv3 RFC, the entire ospf lsdb, areas and spf stuff
is per instance(though is does not state it clearly).
Each instance is logically a separate entity
from other instance running on the same box.
In the MIB draft:

INDEX           { ospfv3AreaId } 
            ::= { ospfv3AreaTable 1 }

Why isn't the instance ID a index in the area table? When a get
is done, what instance's area is accessed. If the next is done
do you go to the same area-id of next instance? Rather it should be
the next area of the same instance.
Shouldn't the instance ID be the first index in all the tables?

The same is the case with other tables too where the instanceId should
be there.

Thanks,
Manoj
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Mar 2006 23:10:48 -0500

Hi Manoj,

Actually, I believe if one were going to take this approach for
supporting multiple OSPFv3 instances, one would have to add instance ID
to every OSPFv3 MIB table index and make every scalar MIB variable a
table indexed by instance ID.

We had this discussion once before for the OSPFv2 MIB and decided 
against it,
in part, due to the fact that RFC 1850 was already published. At that 
time, the
solution we pointed to was to use different SNMPv3 contexts to access MIB
variables for separate protocol instances. However, I don't believe the 
specifics
were ever standardized.

Thanks,
Acee