home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / RIPV2 / 94JUL.MIN < prev    next >
Encoding:
Text File  |  1994-08-08  |  3.5 KB  |  82 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. From: Gary Scott Malkin <gmalkin@xylogics.com>
  4. Date: Wed, 27 Jul 1994 16:39:19 -0400
  5. Subject: RIPv2 minutes
  6.  
  7. CURRENT_MEETING_REPORT_
  8.  
  9. Reported by Gary Malkin/Xylogics, Inc.
  10.  
  11. Minutes of the RIP Version II Working Group (RIPV2)
  12.  
  13.  
  14. Status Update
  15.  
  16.  
  17. Chairpersons        Gary Scott Malkin / gmalkin@xylogics.com
  18.  
  19. Mailing List        ietf-rip(-request)@xylogics.com
  20. Archives        xylogics.com:gmalkin/rip/rip-arc
  21.  
  22. Date of meeting        Toronto IETF / July 26, 1994
  23.  
  24. Progress        Approved RIP-2 protocol and MIB I-Ds for submission
  25.             for consideration as Draft Standards.  Approved
  26.             Protocol Analysis and Applicability Statement I-Ds
  27.             for consideration as Informational RFCs.
  28.  
  29. Agenda
  30.  
  31.     1 - Review the Protocol Analysis I-D
  32.     2 - Review the Applicability Statement I-D
  33.     3 - Discussion of "infinity = 15" problem
  34.     4 - Discussion of Next Hop field usage
  35.     5 - Advancing RIP-2 and Demand Circuit RIP
  36.     6 - Any other issues
  37.     7 - Summary of decisions and actions
  38.  
  39. The Protocol Analysis and Applicability Statement have been accepted as
  40. written.  Pending a modification to the MIB (discussed below), the set
  41. of RIP-2 I-Ds will be submitted for Last Call.
  42.  
  43. Jeffrey Honig reported a problem to the mailing list detailing instances
  44. in which a router may discard a valid route with a metric of 15.  RFC
  45. 1058 specifies that the cost of the interface over which an update was
  46. received (usually 1) is added to the metric advertised in the update.
  47. If that metric is less than Infinity (16), the route is added to the
  48. routing table; otherwise, the route is ignored.  The problem is that some
  49. implementations accept the advertised metric and add the cost of the
  50. outgoing interface to the metric, eliminating routes with a calculated
  51. metric greater than Infinity.  The results of the discussion were that
  52. this is not a serious enough problem to warrent further specification in
  53. the RIP-2 Protocol specification.  There are two reasons for this
  54. determination.  First, there have been many sites running with this
  55. problem for a very long time and it has not caused any routing problems.
  56. At worst, you reduce your network diameter by 1; at best you increase it
  57. by one.  Second, a network with a diameter of 15 should probably not be
  58. running RIP in the first place.
  59.  
  60. The use of the Next Hop field, as described in the Applicability Statement,
  61. was thoroughly discussed.  The objective was to determine that consistant
  62. use of the Next Hop field would not produce routing loops of instabilities.
  63. There was some concern over why one would bother to use the field in this
  64. way (basically, it's a response to users' requests), but there was no
  65. determination that the algorithm was detrimental in any way.
  66.  
  67. The Demand Circuit RIP RFC is currently a Proposed Standard.  It still
  68. has some time to wait before moving to Draft Standard, so no action was
  69. required at this time.
  70.  
  71. Fred Baker introduced a proposal to add MD5 security to RIP-2 as an
  72. extension to the existing password mechanism.  It is essentially the
  73. same proposal adopted by OSPF.  It was decided not to burden RIP-2's
  74. advancement in the standards track with the addition of the new security
  75. measures, so Fred will be producing an Internet Draft which will be
  76. submitted for consideration as a Proposed Standard.  This document will
  77. move independently through the standards track.  A minor change to the
  78. RIP-2 MIB needs to be made to include an MD5 authorization type.  This
  79. change will be added to the MIB I-D immediately.  Since it is simply an
  80. additional value in an existing field, it does not affect the MIB's
  81. advancement in the standards track.
  82.