home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ospf / ospf-minutes-96dec.txt < prev    next >
Encoding:
Text File  |  1997-01-30  |  5.0 KB  |  85 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4.  
  5.     The OSPF Working Group met on Wednesday, December 11th from 1300-2500 at
  6.     the San Jose IETF. Minutes of the meeting follow:
  7.  
  8.     (1) We discussed the issues remaining before the OSPFv2 spec (<draft-
  9.         ietf-ospf-version2-08.txt>) can be submitted for publication as a
  10.         Full Standard, replacing RFC 1583.  John Moy summarized the required
  11.         standardization report (<draft-ietf-ospf-stdreport-00.txt>). One
  12.         incompatible change had been made, resulting in the new
  13.         RFC1583Compatibility flag, which has to be set manually router-by-
  14.         router through SNMP. Two new problems were then described, both of
  15.         which require modifications to the reception of Database Description
  16.         packets in OSPF. Both modifications are backward-compatible.
  17.  
  18.         The first problem, reported by Man-Kit Yeung of cisco, concerns
  19.         retransmissions of the initial Database Description packets (those
  20.         with the Init bit set). These can be continual due to, for example,
  21.         high delay links, in which case the two neighbors will never start
  22.         exchanging databases. The solution is to process these
  23.         retransmissions just as you process duplicate Database Description
  24.         packets in other states.
  25.  
  26.         The second problem, reported by Dan Senie of Proteon, concerns MTU
  27.         mismatches between OSPF neighbors. This can cause flooding between
  28.         the two neighbors to fail, with large Link State Updates being
  29.         continually retransmitted. To fix this, we will report interface MTU
  30.         in Database Description packets. A router will discard received
  31.         Database Description packet which advertise an MTU that is larger
  32.         than the router can receive. In this way, adjacencies will not form
  33.         between routers having MTU mismatches. Tony Li expressed a desire
  34.         for a more general purpose mechanism. There was also a question
  35.         whether the same thing will have to be done for OSPF for IPv6 (we
  36.         think so).
  37.  
  38.     (2) The current OSPF for IPv6 draft (<draft-ietf-ospf-ospfv6-03.txt>)
  39.         was modified to prevent IPv6 link-local addresses from appearing in
  40.         all LSAs except the Link-LSA, where they are used in the next hop
  41.         calculation. The draft will not be submitted to the IETF standards
  42.         track until implementation experience is gained.
  43.  
  44.     (3) Rob Coltun's Opaque-LSA draft (<draft-ietf-ospf-opaque-00.txt>) was
  45.         reviewed.  We intend to submit this for Proposed Standard, as a
  46.         general way to add future extensions to OSPFv2. Jeffrey Zhang asked
  47.         about adding a no-flooding option to the Opaque-LSA flooding scope.
  48.         John Moy responded that standardization of no-flooding was
  49.         unnecessary, as this could be handled equally well via private
  50.         agreements. The Opaque-LSA also has a range of reserved types, which
  51.         we expect will be assigned by IANA.
  52.  
  53.     (4) Doug Williams presented IBM's "QoS Routing Mechanisms and OSPF
  54.         Extensions" (<draft-guerin-qos-routing-ospf-00.txt>). This proposal
  55.         advertises each link's available bandwidth, and optimizes based on
  56.         hop count. Roch Guerin said hop count was used instead of the OSPF
  57.         metric because it is too hard to meaningfully combine additive
  58.         metrics. A good deal of the draft discusses how to efficiently
  59.         precalculate paths with sufficient available bandwidth. A Bellman-
  60.         Ford method and a method using Dijkstra's algorithm are both given;
  61.         the Bellman-Ford is preferred because it doesn't require bandwidth
  62.         quantization (which loses information). Several people mentioned
  63.         that available bandwidth could be advertised in a backward-
  64.         compatible fashion be using OSPF's TOS-encodings.
  65.  
  66.     (5) Patrick Murphy of the U.S. Geological Survey is working on an update
  67.         to OSPF NSSA areas (RFC1587). Import of inter-area routes into NSSA
  68.         areas is being made optional in some cases, and the preference rules
  69.         for the external route calculation are being updated to match the
  70.         latest OSPFv2 spec. Dennis Ferguson wondered whether the resulting
  71.         preferences were metastable. Upon further examination, we think that
  72.         they are OK, but this should be checked by the NSSA authors. Pat
  73.         also described the network where he wants to use NSSA areas: an
  74.         inter-agency network with many OSPF areas, and a lot of
  75.         redistribution of data between OSPF and other routing protocols such
  76.         as IGRP, RIP and IS-IS.
  77.  
  78.     (6) Mark Pullen and Lava Lavu presented an ongoing effort at George
  79.         Mason University to simulate QOSPF. The simulation uses OpNet. They
  80.         have simulated IGMP, RSVP, OSPF, and MOSPF, and are making their
  81.         simulation code publicly available. They only have preliminary
  82.         results, but future results will be available on
  83.         http://bacon.gmu.edu/qosip. They are also looking for people to help
  84.         validate their results.
  85.