RFC 1389 Comments
"Acee Lindem - acee@vnet.ibm.com" <acee@vnet.ibm.com> Tue, 01 June 1993 13:57 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04515;
1 Jun 93 9:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04511;
1 Jun 93 9:57 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa09480;
1 Jun 93 9:57 EDT
Received: by atlas.xylogics.com id AA24085 (5.65c/UK-2.1-930202);
Tue, 1 Jun 1993 09:58:29 -0400
Received: from vnet.ibm.com by atlas.xylogics.com with SMTP
id AA23805 (5.65c/UK-2.1-930202); Tue, 1 Jun 1993 09:58:21 -0400
Message-Id: <23805.199306011358@atlas.xylogics.com>
Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1087;
Tue, 01 Jun 93 09:54:18 EDT
Date: Tue, 1 Jun 93 09:54:55 EDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Acee Lindem - acee@vnet.ibm.com" <acee@vnet.ibm.com>
To: ietf-rip@xylogics.com
Subject: RFC 1389 Comments
With the RIP Version 2 work group re-convening, I would like the following
comments to the rip2 MIB to be considered. The first two have already been
raised by Jeff Honig.
1. Tables indexed on local IP address must account for unnumbered interfaces
(i.e., interfaces that have the same local IP address). The best way to
do this is with an interface index. These tables include
rip2IfStatTable and rip2IfConfTable.
2. With support of multiple rip routing domains, the rip2IfConfTable and
possibly the rip2IfStatTable must also be indexed by routing domain.
3. The rip2GlobalRouteChanges object should be qualified to indicate that a
refresh of the route's age does not constitute a route change.
4. The rip2IfConfDefaultMetric object is not well explained and at least on
the surface looks like a remnant of an implementation. If this implemen-
tation dependent object is to be included than why not support the
objects equivalent to the more general and useful GateD metric-in and
metric-out interface parameters.
5. The rip2IfConfReceive object should support a value indicating not to
listen to rip updates in order to be consistent with the "doNotSend"
value for the rip2IfConfSend object.
6. The new RFC must be more specific as to what constitutes an active peer.
For example, an active peer could be defined as one on an accessible
network which has been heard from in the last 180 seconds.
7. Consideration should be given to coordinating rip2PeerLastUpdate
and rip2PeerVersion. In other words, why replace rip2PeerLastUpdate
with rip2PeerLastPacket or define rip2PeerVersion to be the version
of the last update packet.
Thanks,
- RFC 1389 Comments Acee Lindem - acee@vnet.ibm.com