Re: DECnet MIB question (3)

[Debasis Dalapati <[e-mail]>]

Jon,

Thanks for your reply.

Here are my comments.

>1. Zero Counters on a per circuit basis.
	(stuffs deleted)

Monitoring counters on a per circuit basis may not have been a necessity in
the past but I think it is going to be useful in future as various kind of
interfaces and data link layer protocols are used under DECnet network layer.

I really do not see much of a complexity; the phivCircuitCountZeroCount has
to be made part of the phivCircuitCountEntry.

But for the time being, I am happy as long as I can quote the RFC.

>2. On the two Adjacency Listen Timers.
	(stuffs deleted)

Your proposal is absolutely fine. But, I did not see any difference in the
RFC1289 description and your new description of phivAdjListenTimer. And I do
not think there is necessity of any new description.

>>Jon Saperia wrote:
>>
>>3.  The index for adjacencies.
>>
>>Mark Sylor points out that: In DECNet Phase IV, (at least in the NICE
>>protocol and in the NCP utility) an adjacency does have what corresponds
>>to two indices. One is the name of the circuit, one is the node address
>>of the adjacent node.
>>
>>I just wanted to underscore what John had sent in a previous note about
>>the adjacency index.  I believe that this was discussed (either on the
>>mailing list or at one of our working group meetings - don't remember
>>which).  The simple, single index does allow for unique identification,
>>if not as tidy as the tuple would be - and does have the advantages that
>>John Shriver pointed out.  It is clear the current description should be
>>reworded to be:
>>
>>	"A unique index value for each known adjacency."
>
>Art Berggreen wrote:
>
>If you are saying that the object phivAdjCircuitIndex should be defined
>as a unique identifier across all adjacencies, then I think we need a
>new object which specifies which DECnet Circuit the adjacency has been
>formed across.
>
>If you are just refering to the instantiation of the adjacency table
>members, then the INDEX clause needs to refer to something other than
>phivAdjCircuitIndex.  There could be a new object (say phivAdjIndex)
>which relects this value.
>
>Either a purely local index or an instance composed of circuit ID and
>adjacency node ID will work.  The major advantage of a structured instance,
>is during partial table references.  If one wants to find the adjacencies
>on a particular circuit, the unique identifier requires a full table scan.
>Also, if the circuit ID and Adjacency node ID are known, and just objects
>in one row of the table are desired, the unique entry identifier must be
>known.  This requires at least one full scan of the table and caching of
>the indexing information.  For a router on several LANs, the adjacecy
>table could be rather large.
>

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.
([e-mail]: 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. 

>4. phivCircuitOrigQueueLimit.
	(stuffs deleted)

For the time being, I could refer your mail and RFC1289 to our routing layer
implementors. But, I think it would be useful to have this object on circuit
basis as the circuits will deal with physical media of various bandwidth.

cheers

debasis