phiv MIB document Status

saperia@tcpjon.ogo.dec.com Fri, 06 November 1992 19:07 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06847; 6 Nov 92 14:07 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06843; 6 Nov 92 14:07 EST
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa14604; 6 Nov 92 14:08 EST
Received: by inet-gw-2.pa.dec.com; id AA01128; Fri, 6 Nov 92 11:03:21 -0800
Received: by nsl.pa.dec.com; id AA12552; Fri, 6 Nov 92 10:27:07 -0800
Received: by nsl.pa.dec.com; id AA12548; Fri, 6 Nov 92 10:27:04 -0800
Received: by inet-gw-2.pa.dec.com; id AA28913; Fri, 6 Nov 92 10:27:02 -0800
Received: by tcpjon.ogo.dec.com (5.57/ULTRIX-fma-071891); id AA03303; Fri, 6 Nov 92 13:30:07 -0500
Message-Id: <9211061830.AA03303@tcpjon.ogo.dec.com>
To: phiv-mib@pa.dec.com
Cc: saperia@tcpjon.ogo.dec.com
Subject: phiv MIB document Status
Date: Fri, 06 Nov 92 13:30:06 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: saperia@tcpjon.ogo.dec.com
X-Mts: smtp

Folks,

Now that INTEROP is over, I am attempting to get us back in sync
regarding what to do about the phiv MIB document and how it evolves.
Shortly before INTEROP, you will remember a person asked what they should
do about the new adjacency table.

Jeff Case suggested that one possible approach is to start working on
the DRAFT version of the document now and have it ready after we prove
interoperabilty.  The most important consideration is that we avoid
having people implement the old table so that they do not have to
re-implement.  Given that there are still (to the best of my knowledge)
no products actually shipping, this should not be too much of a problem.

In short I propose the following steps and ask for people to comment:

   1.  We start working on a document that we intend to have issued as a
   draft standard and have it ready simultaneously with interoperable
   demonstrations.  We can hold off on asking that the document be moved
   forward for some period to ensure added 'safety'.

   2.  Obviously this will cause people to want to implement this
   document over the proposed standard (current) document.  This has the
   advantage of getting people to implement the right thing.  I see this
   approach as being better than turning the document over at proposed
   again since the only committed changes are this table fix, and a typo
   (space missing).  After this section, I will list what I believe are
   the changes and remaining open questions for the next turn of the
   document. 

   3.  We need to do some interoperabilty testing no matter what and I
   am requesting suggestions for when people think that they might be
   ready for such tests.  Obviously the answer to this question will
   have a definite impact on what we do with my previous two points.
 
Confirmed 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 to the MIB

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. Please vote early
   and often on this one. 

   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.  Please also vote early and often to keep or
   remove this entry.


Thanks
/jon






























		
	------------------------------------------
	Jon Saperia, Digital Equipment Corporation			
	Internet: saperia@tcpjon.ogo.dec.com
	508-496-8333/9929     voice/fax