Re: Adjacency index
saperia@tcpjon.ogo.dec.com Fri, 28 August 1992 14:06 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02293;
28 Aug 92 10:06 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02289;
28 Aug 92 10:06 EDT
Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa07286;
28 Aug 92 10:08 EDT
Received: by inet-gw-2.pa.dec.com; id AA28299; Fri, 28 Aug 92 07:07:12 -0700
Received: by nsl.pa.dec.com; id AA09039; Fri, 28 Aug 92 06:53:03 -0700
Received: by nsl.pa.dec.com; id AA09035; Fri, 28 Aug 92 06:53:03 -0700
Received: by inet-gw-2.pa.dec.com; id AA27576; Fri, 28 Aug 92 06:53:00 -0700
Received: by tcpjon.ogo.dec.com (5.57/ULTRIX-fma-071891); id AA10320;
Fri, 28 Aug 92 09:55:33 -0400
Message-Id: <9208281355.AA10320@tcpjon.ogo.dec.com>
To: Bob Stewart <rlstewart@eng.xyplex.com>
Cc: saperia@tcpjon.ogo.dec.com, phiv-mib@pa.dec.com
Subject: Re: Adjacency index
In-Reply-To: Your message of "Thu,
27 Aug 92 13:41:27 CDT." <9208271841.AA05254@xap.xyplex.com>
Date: Fri, 28 Aug 92 09:55:32 -0400
From: saperia@tcpjon.ogo.dec.com
X-Mts: smtp
Bob wrote: >Right. I didn't think of that. Actually, we may have done something truly >bizarre and indexed by a useful integer but returned the circuit index for the >allegedly corresponding MIB object. Or maybe not. That's academic. In any >case the MIB is decidedly broken and it seems marking the table obsolete and >replacing it with the double indexed one is the right answer. I am not sure that the current mib could not be fixed (and retain the single index) as we discussed or is 'decidedly broken' - that discussion is somewhat academic though. I believe we have reached an informed consensus on this issue. To use some of Bob's words we will "Do what's right" and when turn to draft we will obsolete the existing Adjacency table with the single index even though that means more work for developers. The consensus is that it is not a hard task and at least one person who has implemented it has said they would be willing to do the recoding. By doing this now rather than later - we can give people a heads up. Before I put in the table in it's entirety I have two questions which we need to get clearly answered: Where should I put the new table in the MIB, at the end of the Adjacency group so as to leave all the existing OID's the same? Or should I overlay the new table onto the old and just have some ASN.1 comments explaining what we did? Since I am not at all sure about this, I have copied Chuck and ask that he let us know since apparently this has come up recently with other MIBs. The one item that makes things simpler in this case is that all that is in the adjacency group is the table in question, so if we need to obsolete the entire group, that will be no different that making the table obsolete. That then would leave the question of where to insert the new group. The second is about phivAdjCircuitIndex. Why I was thinking about using the same value as the index out of the circuit table is that management stations might want to collect other circuit information when looking at adjacency (in this case, obviously they would have to get the circuit name - which is in the circuit table). The idea here was that we would have something that is conceptually similar to the new augments function in the SMP proposal. Several other tables in this MIB (e.g, Link and DDCMP) also use CircuitIndex as well. I do not have hard opinions about this, if the majority want to keep it simple and just have the circuit names with an object identical to the one we have in the circuit table, I am happy to do that, in fact I use that in the example below. The side benefit of doing this is that you can get all the adjacency information for a given circuit together (at least that is how I would tell and agent implementer to do it). Please note that this would be a variable length index which I think is better coded as an OCTET STRING rather than DisplayString for this purpose since the first octet of the index will the length. I think it has to be this way given the variable length of circuit names. Also I changed the name of the object to be phivAdjCircuitName which I think is more generally descriptive of this object when used this way. If we elect to use and index, I would change the name again. So, I hope we are done on this issue. I would like to hear if anybody feels this is an undue hardship (which I do not think) and what their preference for the coding of the index should be. I will leave it to Chuck Davin to comment about where to put the new and deprecated tables. phivAdjTable OBJECT-TYPE SYNTAX SEQUENCE OF PhivAdjEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Adjacency Table." ::= { adjacency 1 } phivAdjEntry OBJECT-TYPE SYNTAX PhivAdjEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "There is one entry in the table for each adjacency." INDEX { phivAdjCircuitName, phivAdjNodeAddr } ::= { phivAdjTable 1 } PhivAdjEntry ::= SEQUENCE { phivAdjCircuitName OCTET STRING, phivAdjNodeAddr PhivAddr, phivAdjBlockSize INTEGER, phivAdjListenTimer INTEGER (1..65535), phivAdjCircuitEtherServPhysAddr OCTET STRING, phivAdjType INTEGER, phivAdjState INTEGER, phivAdjPriority INTEGER, phivAdjExecListenTimer INTEGER (1..65535) } phivAdjCircuitName OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The name of the circuit over which the adjacency is realized. This combined with the phivAdjNodeAddr give a unique index into this table." ::= { phivAdjEntry 1 } phivAdjNodeAddr OBJECT-TYPE SYNTAX PhivAddr -- OCTET STRING (SIZE (2)) ACCESS read-only STATUS mandatory DESCRIPTION "The address of the adjacent node." ::= { phivAdjEntry 2 } phivAdjBlockSize 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." ::= { phivAdjEntry 3 } 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 } phivAdjCircuitEtherServPhysAddr 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." ::= { phivAdjEntry 5 } phivAdjType 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)" ::= { phivAdjEntry 6 } phivAdjState 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 (phivAdjType) 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 (phivAdjType) 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." ::= { phivAdjEntry 7 } phivAdjPriority OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "Priority assigned by the adjacent node for this circuit." ::= { phivAdjEntry 8 } 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 }
- Adjacency index saperia
- Adjacency index John A. Shriver
- Adjacency index John A. Shriver
- Re: Adjacency index Bob Stewart
- Re: Adjacency index saperia
- Adjacency index John A. Shriver
- Re: Adjacency index Bob Stewart
- Re: Adjacency index saperia
- Re: Adjacency index Art Berggreen
- Re: Adjacency index saperia
- Re: Adjacency index Bob Stewart
- Re: Adjacency index saperia
- Re: Adjacency index saperia
- Re: Adjacency index Debasis Dalapati
- Re: Adjacency index Debasis Dalapati
- Re: Adjacency index saperia
- Re: Adjacency index Art Berggreen
- Re: Adjacency index Debasis Dalapati
- Re: Adjacency index saperia
- Re: Adjacency index saperia