Re: DECnet MIB question (3)

Debasis Dalapati <> Fri, 21 August 1992 19:01 UTC

Received: from by IETF.NRI.Reston.VA.US id aa04988; 21 Aug 92 15:01 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab04984; 21 Aug 92 15:01 EDT
Received: from by NRI.Reston.VA.US id aa14209; 21 Aug 92 15:02 EDT
Received: by; id AA27006; Fri, 21 Aug 92 12:02:13 -0700
Received: by; id AA21305; Fri, 21 Aug 92 11:12:42 -0700
Received: by; id AA21301; Fri, 21 Aug 92 11:12:41 -0700
Received: by; id AA24177; Fri, 21 Aug 92 11:12:40 -0700
Received: by bagate.BELL-ATL.COM (/\==/\ Smail3.1.25.1 #25.29)id <m0mLdUv-0000byC@bagate.BELL-ATL.COM>; Fri, 21 Aug 92 14:14 EDT
Received: by (4.1/SMI-4.1)id AA10898; Fri, 21 Aug 92 14:23:43 EDT
Date: Fri, 21 Aug 92 14:23:43 EDT
From: Debasis Dalapati <>
Message-Id: <>
Subject: Re: DECnet MIB question (3)

>> (debasis dalapati) wrote:
>>I am in agreement with Art regarding the concept. But, I am not sure if any
>>new object is needed. Just modification of the INDEX specification to use
>>the tuple ( phivAdjCircuitIndex, phivAdjNodeAddr ) should be sufficient.
>>I am not clear about how the simple, single index of phivAdjCircuitIndex 
>>allows for unique identification.
>>( I didn't meant double indexing through both
>>phivAdjCircuitIndex and phivAdjNodeAddr in my original question.) 
>>My comment is, why keep the unique identification mechanism implementation
>>dependent when it could be done through the use of existing objects in the
>>table entry. Also, ( phivAdjCircuitIndex, phivAdjNodeAddr ) tuple would be
>>more appropriate than ( phivAdjNodeAddr, phivAdjCircuitIndex ) tuple as
>>multiple adjacencies to same node through more than one circuit would be
>>relatively rare. 
> (Art Berggreen) replied:
>I believe that the two part instance that the tuple (phivAdjCircuitIndex,
>phivAdjNodeAddr) implies is what John is trying to avoid.  I'd accept the
>single, unique local identifier easier if the values are not required to
>be consecutive and the size can be up to 32 bits.  This would allow me to
>form my unique identifiers as ( (circuit_index * 65536) + adj_addr ).
>Since this a local identifier, someone else's box could use whatever they


I am not trying to find out or propose how a management instrumentation
could/should  manage the adjacency table. 
I am just trying to figure out which adjacency information should be returned
to a management station for a get-next request.
The INDEX specification is very important for that purpose. No matter how many
different vendors routers is managed by a management station, it should get
the similar response from all the DECnet routers. An agent is free to 
implement and maintain the adjacency table in any manner it wants to but when
responding to a management station's request, adjacency information has to
be returned in a predefined manner. The management station should not have
to rearrange the retrieved information based on which agent it is dealing with.