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
- DECnet IV MIB issues... Don Dewar
- DECnet IV MIB issues... John A. Shriver
- Re: DECnet IV MIB issues... Bob Stewart
- DECnet IV MIB issues... Jon Saperia
- DECnet IV MIB issues... Jon Saperia