RIPv2 minutes
Gary Scott Malkin <gmalkin@xylogics.com> Wed, 27 July 1994 20:48 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07416; 27 Jul 94 16:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07412; 27 Jul 94 16:48 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa14332; 27 Jul 94 16:48 EDT
Received: by atlas.xylogics.com id AA32080 (5.65c/UK-2.1-940401); Wed, 27 Jul 1994 16:39:22 -0400
Received: by atlas.xylogics.com id AA27836 (5.65c/UK-2.1-940401); Wed, 27 Jul 1994 16:39:19 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Gary Scott Malkin <gmalkin@xylogics.com>
Date: Wed, 27 Jul 1994 16:39:19 -0400
Message-Id: <27836.199407272039@atlas.xylogics.com>
To: ietf-rip@xylogics.com
Cc: minutes@CNRI.Reston.VA.US
Subject: RIPv2 minutes
CURRENT_MEETING_REPORT_ Reported by Gary Malkin/Xylogics, Inc. Minutes of the RIP Version II Working Group (RIPV2) Status Update Chairpersons Gary Scott Malkin / gmalkin@xylogics.com Mailing List ietf-rip(-request)@xylogics.com Archives xylogics.com:gmalkin/rip/rip-arc Date of meeting Toronto IETF / July 26, 1994 Progress Approved RIP-2 protocol and MIB I-Ds for submission for consideration as Draft Standards. Approved Protocol Analysis and Applicability Statement I-Ds for consideration as Informational RFCs. Agenda 1 - Review the Protocol Analysis I-D 2 - Review the Applicability Statement I-D 3 - Discussion of "infinity = 15" problem 4 - Discussion of Next Hop field usage 5 - Advancing RIP-2 and Demand Circuit RIP 6 - Any other issues 7 - Summary of decisions and actions The Protocol Analysis and Applicability Statement have been accepted as written. Pending a modification to the MIB (discussed below), the set of RIP-2 I-Ds will be submitted for Last Call. Jeffrey Honig reported a problem to the mailing list detailing instances in which a router may discard a valid route with a metric of 15. RFC 1058 specifies that the cost of the interface over which an update was received (usually 1) is added to the metric advertised in the update. If that metric is less than Infinity (16), the route is added to the routing table; otherwise, the route is ignored. The problem is that some implementations accept the advertised metric and add the cost of the outgoing interface to the metric, eliminating routes with a calculated metric greater than Infinity. The results of the discussion were that this is not a serious enough problem to warrent further specification in the RIP-2 Protocol specification. There are two reasons for this determination. First, there have been many sites running with this problem for a very long time and it has not caused any routing problems. At worst, you reduce your network diameter by 1; at best you increase it by one. Second, a network with a diameter of 15 should probably not be running RIP in the first place. The use of the Next Hop field, as described in the Applicability Statement, was thoroughly discussed. The objective was to determine that consistant use of the Next Hop field would not produce routing loops of instabilities. There was some concern over why one would bother to use the field in this way (basically, it's a response to users' requests), but there was no determination that the algorithm was detrimental in any way. The Demand Circuit RIP RFC is currently a Proposed Standard. It still has some time to wait before moving to Draft Standard, so no action was required at this time. Fred Baker introduced a proposal to add MD5 security to RIP-2 as an extension to the existing password mechanism. It is essentially the same proposal adopted by OSPF. It was decided not to burden RIP-2's advancement in the standards track with the addition of the new security measures, so Fred will be producing an Internet Draft which will be submitted for consideration as a Proposed Standard. This document will move independently through the standards track. A minor change to the RIP-2 MIB needs to be made to include an MD5 authorization type. This change will be added to the MIB I-D immediately. Since it is simply an additional value in an existing field, it does not affect the MIB's advancement in the standards track.
- RIPv2 minutes Gary Scott Malkin