Two more DECnet questions

"John A. Shriver" <> Fri, 21 August 1992 22:24 UTC

Received: from by IETF.NRI.Reston.VA.US id aa08545; 21 Aug 92 18:24 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08541; 21 Aug 92 18:24 EDT
Received: from by NRI.Reston.VA.US id aa18497; 21 Aug 92 18:25 EDT
Received: by; id AA08336; Fri, 21 Aug 92 15:17:26 -0700
Received: by; id AA00894; Fri, 21 Aug 92 14:27:45 -0700
Received: by; id AA00890; Fri, 21 Aug 92 14:27:44 -0700
Received: by; id AA03446; Fri, 21 Aug 92 13:56:41 -0700
Received: from by (5.65/1.8)id AA19352; Fri, 21 Aug 92 16:56:05 -0400
Received: by (3.2/SMI-3.2)id AA19507; Fri, 21 Aug 92 16:55:55 EDT
Date: Fri, 21 Aug 92 16:55:55 EDT
From: "John A. Shriver" <>
Message-Id: <>
In-Reply-To: Art Berggreen's message of Fri, 21 Aug 92 12:56:51 PDT <>
Subject: Two more DECnet questions

   Date: Fri, 21 Aug 92 12:56:51 PDT
   From: (Art Berggreen)

   If an implementation maintains multiple equal-cost routes to a node (L1)
   or an area (L2), the current MIB definitions only allows one of those
   routes to appear in the relevant tables.  Is this a problem?

I suspect that DEC didn't want to put that in because that is part of
DECnet Phase IV+, for which the specifications have never been
released for internal (political? manpower? willpower?) reasons.
Putting it in the MIB would further increase the embarrasment that the
DEC has two versions of DECnet, one they publish (Phase IV), one they
use (Phase IV+).  (Shades of "see figure one"...)

Phase IV+ is not very common outside of DEC implmentations, and I
guess one would just export the "first" route.

   Now that Token Ring (and FDDI?) encapsulation and usage is defined, should
   all references to Ethernet be generalized to LAN?

The token ring encapsulation adds more to the protocol than would be
supported by the current MIB.  We should leave that for the future.

I suppose FDDI should be allowed.  While that spec is not published,
either, it's awful obvious: the way it comes out of a Ethernet/FDDI