RIPv2 minutes

Gary Scott Malkin <> Wed, 27 July 1994 20:48 UTC

Received: from 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 by CNRI.Reston.VA.US id aa14332; 27 Jul 94 16:48 EDT
Received: by id AA32080 (5.65c/UK-2.1-940401); Wed, 27 Jul 1994 16:39:22 -0400
Received: by 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 <>
Date: Wed, 27 Jul 1994 16:39:19 -0400
Message-Id: <>
Cc: minutes@CNRI.Reston.VA.US
Subject: RIPv2 minutes


Reported by Gary Malkin/Xylogics, Inc.

Minutes of the RIP Version II Working Group (RIPV2)

Status Update

Chairpersons		Gary Scott Malkin /

Mailing List		ietf-rip(-request)

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.


	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.