What to do with Adjacency table until we make the fix going to draft
saperia@tcpjon.ogo.dec.com Sat, 17 October 1992 23:04 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03106; 17 Oct 92 19:04 EDT
Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03102; 17 Oct 92 19:04 EDT
Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa14207; 17 Oct 92 19:05 EDT
Received: by inet-gw-2.pa.dec.com; id AA25856; Sat, 17 Oct 92 16:02:25 -0700
Received: by nsl.pa.dec.com; id AA21658; Sat, 17 Oct 92 15:19:03 -0700
Received: by nsl.pa.dec.com; id AA21654; Sat, 17 Oct 92 15:19:02 -0700
Received: by inet-gw-2.pa.dec.com; id AA23827; Sat, 17 Oct 92 15:19:01 -0700
Received: by tcpjon.ogo.dec.com (5.57/ULTRIX-fma-071891); id AA22219; Sat, 17 Oct 92 18:21:04 -0400
Message-Id: <9210172221.AA22219@tcpjon.ogo.dec.com>
To: rndi!rnd!rina@uunet.uu.net
Cc: phiv-mib@pa.dec.com, saperia@tcpjon.ogo.dec.com
Subject: What to do with Adjacency table until we make the fix going to draft
Date: Sat, 17 Oct 1992 18:21:04 -0400
Sender: ietf-archive-request@IETF.NRI.Reston.VA.US
From: saperia@tcpjon.ogo.dec.com
X-Mts: smtp
Segdan, A couple of things: 1. I have added you to the phiv-mib distribution list so that you can talk with others who are interested and are working on similar implementations. 2. I have forwarded your note to the group since I wanted to have them have an opportunity to disagree whith my answer to you about what to do in the interim. 3. I think it is in everyone's best interest if we agree on an interim implementation approach until the RFC is fixed. 4. My response: You observe correctly that the RFC as currently written has a problem with the Adjacency Index. This mailing list had a fairly log discussion about what to do. I will forward you separately, the final proposal for a fixed table. In short, we plan to obsolete the current table and put in a new table which is nearly identical to the current table except that its index is both the circuit index and the node addr. After much discussion, we concluded that this was the best fix even though there were less radical approaches such as simply having a unique index for each adjacency. While we could do this as an interim approach, I am not sure that this is the best thing to do. This is why I am posting this here. My gut reaction is to suggest that people implementing the MIB use the new table that we proposed which will be placed at the end of the Adjacency group. I think we will get best interoperability this way and have minimal impact when the document is revised. It also will ensure that we do not have OID problems. Comments????? /jon ------- Forwarded Message Return-Path: rndi!rnd!rina@uunet.UU.NET Received: by tcpjon.ogo.dec.com (5.57/ULTRIX-fma-071891); id AA10388; Thu, 15 Oct 92 21:03:20 -0400 Received: by inet-gw-2.pa.dec.com; id AA15046; Thu, 15 Oct 92 18:00:20 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23246; Thu, 15 Oct 92 20:59:07 -0400 Received: from rndi.UUCP by uunet.uu.net with UUCP/RMAIL(queueing-rmail) id 205837.2119; Thu, 15 Oct 1992 20:58:37 EDT Received: by rndi (5.65/1.35)id AA00415; Fri, 16 Oct 92 01:26:01 +0200 Received: by (4.1/SMI-4.1)id AA02914; Thu, 15 Oct 92 12:33:41 IST Date: Thu, 15 Oct 92 12:33:41 IST From: rndi!rnd!rina@uunet.UU.NET (Rina Nethaniel) Message-Id: <9210151033.AA02914@> To: saperia Subject: DecNet MIB Dear sir, We are currently implementing the DECnet Phase IV MIB in our management station. while doing so we came across a problem with the adjacency table. The a djacency table uses circuit index as a key but the adjacency entry is defined as "one entry in the table for each adjacency". In case of Ethernet circuits the r esult is a group of adjacencies that can vary from 1 to 1023. While given an Eth ernet circuit no. what will be returned from the router ? Thank you yours sincerely Segdan Refaela Rad Network Devices ATIDIM Technological Park Bldg. # 1 Tel-Aviv , Israel ------- End of Forwarded Message