DECnet IV MIB issues...

Jon Saperia <saperia@tcpjon.lkg.dec.com> Sat, 17 April 1993 18:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03117; 17 Apr 93 14:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03113; 17 Apr 93 14:29 EDT
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa17395; 17 Apr 93 14:29 EDT
Received: by inet-gw-2.pa.dec.com; id AA11936; Sat, 17 Apr 93 11:27:25 -0700
Received: by nsl.pa.dec.com; id AA29767; Sat, 17 Apr 93 09:37:52 -0700
Received: by nsl.pa.dec.com; id AA29763; Sat, 17 Apr 93 09:37:51 -0700
Received: by pobox1.pa.dec.com; id AA05934; Sat, 17 Apr 93 09:37:49 -0700
Received: by tcpjon.lkg.dec.com (5.57/ULTRIX-fma-071891); id AA01700; Sat, 17 Apr 93 12:41:29 -0400
Message-Id: <9304171641.AA01700@tcpjon.lkg.dec.com>
To: phiv-mib@pa.dec.com
Cc: saperia@tcpjon.lkg.dec.com
Subject: DECnet IV MIB issues...
Date: Sat, 17 Apr 1993 12:41:29 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Jon Saperia <saperia@tcpjon.lkg.dec.com>
X-Mts: smtp

Folks,

I have been getting ready for the show on the west coast so I have not had a
chance to respond until now - and I will probably not get a chance to do much
next week.  I did want to get this out so others could make progress this
comming week.

By now you will all have seen the announcement formalizing what we have
been talking informally about for a few months; where to go with the
current MIB. 

Before we can make a recommendation we need to consolidate required
changes and discuss implementations.  Some months ago, I sent out what I
believed at the time was our complete list of issues with the MIB.
Since that time a couple more questions from other vendors doing
implementations have also come up.  The purpose of this note is to put
everything together in one place so we have a common set of issues on
which to make our decisions.

From previous notes, here is where I think we stand (confirmed/required
changes):

   1.  There is a typo in the current RFC.  A space is missing between
   SYNTAX and INTEGER in phivRouteType { routing 14 }.  This will be
   fixed. 

   2.  We will fix the Adjacency table.  The current table and all
   objects in it will be made obsolete.

   3.  Below is the entire new table.  Please also note that as opposed
   to the drafts we talked about earlier on the mailing list, this table
   is adjacency 2 since adjacency 1 is already taken with the table we
   are going to obsolete:

       phivAdjNodeTable OBJECT-TYPE
           SYNTAX SEQUENCE OF PhivAdjNodeEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
               "The Adjacent Node Table."
           ::= { adjacency 2 }

       phivAdjNodeEntry OBJECT-TYPE
           SYNTAX PhivAdjNodeEntry
           ACCESS not-accessible
           STATUS mandatory
           DESCRIPTION
               "There is one entry in the table for each adjacency."
           INDEX  { phivAdjNodeCircuitIndex, phivAdjAddr }
           ::= { phivAdjNodeTable 1 }

       PhivAdjNodeEntry ::=
           SEQUENCE {
               phivAdjNodeCircuitIndex
                   INTEGER,
               phivAdjAddr
                   PhivAddr,
               phivAdjNodeBlockSize
                   INTEGER,
               phivAdjNodeListenTimer
                   INTEGER (1..65535),
               phivAdjNodeCircuitEtherServPhysAddr
                   OCTET STRING,
               phivAdjNodeType
                   INTEGER,
               phivAdjNodeState
                   INTEGER,
               phivAdjNodePriority
                   INTEGER,
               phivAdjNodeExecListenTimer
                   INTEGER (1..65535)
            }
       phivAdjNodeCircuitIndex OBJECT-TYPE
           SYNTAX INTEGER
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "A unique index value for each known circuit.  This
               value is the same as phivCircuitIndex and identifies the
               circuit over which the adjacency is realized."
           ::= { phivAdjNodeEntry 1 }

       phivAdjAddr OBJECT-TYPE
           SYNTAX PhivAddr -- OCTET STRING (SIZE (2))
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "The address of the adjacent node."
           ::= { phivAdjNodeEntry 2 }

       phivAdjNodeBlockSize OBJECT-TYPE
           SYNTAX INTEGER
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This read-only parameter is the block size that was
               negotiated with the adjacent Routing layer during Routing
               initialization over a particular circuit. It includes the
               routing header, but excludes the data link header. This
               parameter is qualified by ADJACENT NODE."
           ::= { phivAdjNodeEntry 3 }

       phivAdjNodeListenTimer OBJECT-TYPE
           SYNTAX INTEGER (1..65535)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This value determines the maximum number of seconds
               allowed to elapse before Routing receives some message
               (either a Hello message or a user message) from the
               adjacent node on the circuit. It was agreed during
               Routing initialization with the adjacent Routing layer.
               This parameter is qualified by ADJACENT NODE."
           ::= { phivAdjNodeEntry 4 }

       phivAdjNodeCircuitEtherServPhysAddr OBJECT-TYPE
           SYNTAX OCTET STRING ( SIZE (6) )
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This parameter indicates the Ethernet physical address
               of an adjacent node that is being serviced on this
               circuit. This parameter is a qualifier for SERVICE
               SUBSTATE."
           ::= { phivAdjNodeEntry 5 }

       phivAdjNodeType OBJECT-TYPE
           SYNTAX INTEGER {
               routing-III (1),
               nonrouting-III (2),
               area (3),
               routing-IV (4),
               nonrouting-IV (5)
           }
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This parameter indicates the type of adjacency.

               For adjacent nodes, this is a read-only parameter that
               indicates the type of the reachable adjacent node.
               NOTE: The routing-III and nonrouting-III values are
               incremented by one compared to the standard DECnet
               values in order to maintain compliance with RFC 1155)"
           ::= { phivAdjNodeEntry 6 }

       phivAdjNodeState OBJECT-TYPE
           SYNTAX INTEGER {
               initializing (1),          -- Ethernet one-way
               up (2),                    -- Ethernet two-way
               run (3),                   -- The eight DDCMP/X.25 states
               circuit-rejected (4),
               data-link-start (5),
               routing-layer-initialize (6),
               routing-layer-verify (7),
               routing-layer-complete (8),
               off (9),
               halt (10)
           }
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This value indicates the state of a router adjacency.
               On adjacencies over a circuit of type
               (phivCircuitCommonType) Ethernet, CI, or FDDI, with an
               adjacent node of type (phivAdjNodeType) ROUTING IV or AREA,
               this variable is the state of the Ethernet
               Initialization Layer for this adjacency, and can have
               values INITIALIZING or UP. (See Section 9.1.1 of
               DECnet Phase IV Routing Layer Functional Specification.)

               On adjacencies over a circuit of type
               (phivCircuitCommonType) Ethernet, CI, or FDDI, with an
               adjacent node of type (phivAdjNodeType) NONROUTING IV,
               this variable will always take on the value UP.

               On adjacencies over a circuit of type
               (phivCircuitCommonType) DDCMP POINT, DDCMP CONTROL,
               DDCMP TRIBUTARY, DDCMP DMC, or X.25, this variable is
               the state of the Routing Layer Initialization Circuit
               State. (See section 7.3, ibid.)  It can have values
               between RUN and HALT.

               On adjacencies over a circuit of type
               (phivCircuitCommonType) OTHER, this variable may be
               used in a manner consistent with the Initialization
               Layer used on that circuit."
           ::= { phivAdjNodeEntry 7 }

       phivAdjNodePriority OBJECT-TYPE
           SYNTAX INTEGER (0..255)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "Priority assigned by the adjacent node for this
               circuit."
        ::= { phivAdjNodeEntry 8 }

       phivAdjNodeExecListenTimer OBJECT-TYPE
           SYNTAX INTEGER (1..65535)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This read-only value determines the maximum number of
               seconds allowed to elapse before Routing receives some
               message (either a Hello message or a user message) from
               the adjacent node on the circuit. It was agreed during
               Routing initialization with the adjacent Routing layer."
           ::= { phivAdjNodeEntry 9 }

Requested Changes other items to discuss form previous notes

I have had only two additional requests for changes/additions to the
MIB, they are:

   1.  There is no object which shows Multicast Bytes Sent.  There is
   an object, phivCountersCountMcastBytesRecd.  A number of people have
   suggested that phivCountersCountMcastBytesSent might be interesting.
   In discussions of this on the mailing list in the past, it has been
   pointed out that this was not included in the original MIB because it
   was not part of the original DECNet Management Spec.  Please also
   note that there is no analog for phivCountersCountMcastBlksRecd
   either.  My desire is for stability at this point.  I do not want to
   add phivCountersCountMcastBytesSent unless there is a compelling
   reason with a reasonable consensus that we add it.  The fact that it
   was not in the original spec does not matter very much to me, if 
   people feel it really needs to be added we can do it.

   2.  In the original, and currently proposed, Adjacency table, there
   are objects phivAdjListenTimer and phivAdjExecListenTimer See below:

       phivAdjListenTimer OBJECT-TYPE
           SYNTAX INTEGER (1..65535)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This value determines the maximum number of seconds
               allowed to elapse before Routing receives some message
               (either a Hello message or a user message) from the
               adjacent node on the circuit. It was agreed during
               Routing initialization with the adjacent Routing layer.
               This parameter is qualified by ADJACENT NODE."
           ::= { phivAdjEntry 4 }
.
.
.
       phivAdjExecListenTimer OBJECT-TYPE
           SYNTAX INTEGER (1..65535)
           ACCESS read-only
           STATUS mandatory
           DESCRIPTION
               "This read-only value determines the maximum number of
               seconds allowed to elapse before Routing receives some
               message (either a Hello message or a user message) from
               the adjacent node on the circuit. It was agreed during
               Routing initialization with the adjacent Routing layer."
           ::= { phivAdjEntry 9 }

   I have had a single request that we remove phivAdjExecListenTimer to
   simplify this table.  The difference is not really clear to people so
   I would certainly entertain other votes to remove
   phivAdjExecListenTimer. 


   3.  Many people on this list have explained why we have separate
   counters for LINK and LINE utilizations so I will not go into that
   here.  The counters most often in question are:

        phivCountersCountDataBlocksRecd
        phivCountersCountDataBlksRecd
        phivCountersCountDataBlocksSent
        phivCountersCountDataBlksSent

   I remember that we discussed the need for these counters during the
   early stages of the MIB development.  In fact, John Shriver sent out
   a note explaining the distinction between counting information for
   DECNet LINKs and LINEs.

   Clearly what has happened is that during the editing stages we messed
   up and it was not caught.  While we did preserve the Blocks and Blks
   entries to have separate objects for LINK and LINE Data Blocks sent
   and received, we did not catch the fact that the OBJECT DESCRIPTIONS
   were the same. 

   Given that the group into which these object fall has the following
   conformance language: 

       -- Counters Group

       -- The implementation of the Counters Group is mandatory for
       -- systems which only support DECnet style locking counters.

I need to ask, has anybody implemented these objects?  Based on the
answer to this question, I see the following options:

       1.  If nobody has implemented the group, and there is a clear
       consensus that it has proved to be not useful, we can eliminate
       the entire group and this problem along with it.

       2.  If people do want to keep the group, I would be interested to
       learn if anybody has implemented it (or are planning to implement
       it) and if so, what was done with these objects.  One possibility
       is to just keep one pair and only count, for example, link data.

       3.  If we want to keep the group - given that this question comes
       up frequently, I suggest we fix the descriptors for each of these
       objects to cause one set to reflect LINE and the other to reflect
       LINK information.

   4.  Lastly Don Dewar posted some questions to this list which I will
   not detail here, but which have had some reasonable replies by John
   Shriver and Bob Stewart.  I hope these answers resolve this issues,
   otherwise we will need specific proposals for change.

/jon		
	------------------------------------------
	Jon Saperia, Digital Equipment Corporation			
	Internet: saperia@lkg.dec.com
	508-486-5959