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 1992 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
- phiv MIB document Status saperia
- Re: phiv MIB document Status Bob Stewart