home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
- Reported by Gary Malkin/Xylogics
-
- Minutes of the RIP Version II Working Group (RIPV2)
-
-
- Agenda
-
- o Review the protocol analysis Internet-Draft
- o Review the applicability statement Internet-Draft
- o Discussion of ``infinity equals 15'' problem
- o Discussion of next hop field usage
- o Advancing RIP-2 and demand circuit RIP
- o Any other issues
- o Summary of decisions and actions
-
-
- Summary
-
- The protocol analysis and applicability statement Internet-Drafts have
- been accepted as written. Pending a modification to the MIB (discussed
- below), the set of RIP-2 Internet-Drafts 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 warrant 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 consistent use of the next hop field would not produce routing
- loops or instabilities. There was some concern over why one would
- bother to use the field in this way (basically, it is 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 Internet-Draft immediately. Since it is
- simply an additional value in an existing field, it does not affect the
- MIB's advancement in the standards track.
-
-
- Progress
-
- The RIP-2 protocol and MIB Internet-Drafts were approved for submission
- as Draft Standards. The protocol analysis and applicability statement
- Internet-Drafts were also approved to be submitted as Informational
- RFCs.
-
-