home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ospf / ospf-minutes-92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  9.6 KB  |  193 lines
  1. This is a rough draft - Megan 04/06/92
  2.  
  3. Hi. Here are the minutes of the last OSPF Working group meeting. I
  4. have referenced the handwritten slides that people presented;
  5. unfortunately to see them you'll have to get a copy from the
  6. proceedings. It reads pretty well without them though...
  7.  
  8. John
  9.  
  10. ------------------------ cut here ----------------------------------
  11.  
  12.  
  13.  
  14.  
  15.                      OSPF WG minutes: March 92 meeting
  16.  
  17.     The OSPF Working Group met at the March 1992 IETF in San Diego. The
  18.     minutes from that meeting follow.
  19.  
  20.     The meeting began with an announcement that IP multicast has been
  21.     assigned an 802.5 functional address. This affects OSPF over 802.5,
  22.     since many OSPF control packets (Hellos, etc.) are sent as IP
  23.     multicasts. The functional address assignment will be documented in
  24.     a short RFC, probably written by Steve Deering. It was suggested
  25.     that to aid in the transition from the 802.5 broadcast address to
  26.     the new functional address, a configuration knob be provided in OSPF
  27.     implementations to select between broadcast/functional address. In
  28.     any case, by the principle of "be liberal in what you receive", you
  29.     should not reject a packet whose link level destination is the
  30.     broadcast if you are instead expecting the functional address (this
  31.     would enable a staged transition to the functional address, where
  32.     you first enable reception of the functional address, and then in
  33.     some future release start sending it).
  34.  
  35.     There are now a number of OSPF documents that will soon be ready for
  36.     publication as RFCs: reissues of the base spec and the OSPF MIB, the
  37.     OSPF Trap MIB, and the OSPF NSSA document. It is likely that these
  38.     documents will want to reference each other, which may cause some
  39.     logistical problems since you can't reference Internet Drafts (maybe
  40.     they'll have to be issued as a set). In any case, it was decided to
  41.     delay the publication of these documents until there were at least
  42.     two interoperable implementations.
  43.  
  44.     During the main part of the meeting, the following issues were
  45.     discussed:
  46.  
  47.     o   We reviewed proposed changes to the base OSPF spec (RFC 1247).
  48.         These changes are: a fix to a bug found in certain virtual link
  49.         configurations, updating the TOS representation to include the
  50.         new monetary cost bit, making summarization of routes into stub
  51.         areas optional and an optimization to summarizing routes into
  52.         transit areas.  At the previous IETF a different fix to virtual
  53.         link problem was discussed and rejected due to its complexity.
  54.         The present fix, suggested independently be several people, is
  55.         much simpler. Part of the fix involves removing the ability to
  56.         assign a cost of LSInfinity to router interfaces. The fans of
  57.         Strong TOS (e.g., Milo and John Lekashman) were against this.
  58.         John Moy was assigned the action item of further explaining why
  59.         LSInfinity was a problem, and then negotiating with Milo and
  60.         John. Fred Baker also mentioned that he had come across a
  61.         situation where he wanted to condense inter-area routing
  62.         information (not just intra-area, as specified in the current
  63.  
  64.  
  65.  
  66.                                   [Page 1]
  67.  
  68.  
  69.  
  70.         spec), but that the provision making summarization into stub
  71.         areas optional would serve just as well.
  72.  
  73.         The proposed changes to RFC 1247 will be published shortly as an
  74.         Internet Draft, followed by a revised version of the OSPF spec.
  75.         All changes are backward compatible; there will be no need to
  76.         increase the OSPF version number.
  77.  
  78.     o   Rob Coltun presented a collection of backward-compatible
  79.         additions to the OSPF MIB. These additions included three
  80.         variables to deal with OSPF Database Overflow: LSDBHiWater
  81.         (read-only; the largest number of LSAs that have ever been in
  82.         the router's database), LSDBOverflowWarning (read/write; when
  83.         the number of LSAs hits this number a trap is generated) and
  84.         LSDBLimit (read/write; when the number of LSAs hits this number
  85.         the router takes further action to limit the size of the
  86.         database as specified in a document to be written by John Moy).
  87.         Also, a new table for type 5 external-LSAs is to be included,
  88.         since in the current MIB it is not clear in which area
  89.         ospfLsdbTable these LSAs should be reported. Fred Baker
  90.         explained that, in order to be backward compatible, it would
  91.         still be legal to report the type 5 externals LSAs in the old
  92.         ospfLsdbTable.
  93.  
  94.         It was also noted that there should be two new ospfLsdbType
  95.         values: 6 (for the group-membership-LSAs) and 7 (for the LSAs
  96.         used by NSSA areas). In addition, since the interface cost
  97.         LSInfinity is being removed, the comment in the
  98.         ospfIfMetricMetric entry ("The value FFFF is distinguished to
  99.         mean 'no router via this TOS'") should be removed.
  100.  
  101.         Jeff Honig brought up a list of MIB variables that were named
  102.         inconsistently. According to Fred Baker, we do not have to
  103.         maintain the ascii text representation of MIB variables to
  104.         qualify for backward-compatibility, even though this may be an
  105.         inconvenience to certain network management stations. Rob, Fred
  106.         and Jeff are to go though the MIB to see which variables warrant
  107.         renaming.
  108.  
  109.     o   Rob Coltun summarized the state of the OSPF Trap MIB (see Slide
  110.         2) which is very near to being finalized. There was some
  111.         discussion on the best strategy for inhibiting traps when a
  112.         router first starts, with the arguments for and against
  113.         inhibiting traps on a per-interface basis being rehashed once
  114.         again.
  115.  
  116.     o   Jeff Honig brought up the issue on how the OSPF MIB could handle
  117.         multiple instances of OSPF running in the same box. While there
  118.  
  119.  
  120.  
  121.                                   [Page 2]
  122.  
  123.  
  124.  
  125.         is a straightforward technical solution to this problem
  126.         (basically adding another index to all the MIB's tables), this
  127.         is not backward-compatible and was viewed by several people as
  128.         making the MIB overly complicated. Fred Baker suggested that
  129.         this was a larger issue than just for OSPF, and suggested that
  130.         we pass the problem (namely, how to monitor several instances of
  131.         a protocol) on to the network management working group.
  132.  
  133.     o   Rob Coltun and Vince Fuller have completed a document describing
  134.         the OSPF Not-so-stubby-area (NSSA) option, adding a motivational
  135.         section to the outline that was presented the previous meeting
  136.         (Santa Fe), and completing the technical details. Rob presented
  137.         an overview of the NSSA support, together with some of the more
  138.         non-obvious details (see slide 3). Basically, NSSAs are a new
  139.         type of area, similar to OSPF stub areas in that they do not
  140.         handle type 5 external-LSAs (and so routers internal to these
  141.         areas require less resources). However, NSSAs are capable of
  142.         importing external information of their own, which will be
  143.         converted to normal type 5 LSAs at the NSSA boundary.  This
  144.         enables, for example, RIP clouds to be hung off of NSSA areas.
  145.  
  146.         Discussion centered upon whether we should be multiplexing
  147.         several functions onto a single OSPF options bit (now that they
  148.         are getting scarce), and the correct way to model the
  149.         translation of external information that takes place at the NSSA
  150.         boundary.
  151.  
  152.     o   Rob Coltun and Jeff Honig presented a proposal for another new
  153.         OSPF option, which they called the PRI (Peripheral Router
  154.         Interconnect) option (see Slides 4-7). This would provide a way
  155.         to configure a set of distinguished OSPF routers, which would
  156.         automatically discover each other and then be able to exchange
  157.         additional information formatted as new LSA types. Jeff Honig
  158.         explained an application of this whereby the PRI routers could
  159.         exchange AS path information, obviating the need for IBGP. Rob
  160.         and Jeff intend to write this up in more detail.
  161.  
  162.     o   Osmund deSouza led a discussion on how to run OSPF over Frame
  163.         relay (slides 9-12). One concern was that, since in real Frame
  164.         relay networks you are unlikely to have full mesh connectivity
  165.         for PVCs, the NBMA model does not apply. In these cases, the
  166.         Frame relay would have to be treated as a collection of point-
  167.         to-point links.  A number of people thought that it might be
  168.         possible to model Frame relay as a collections of some number of
  169.         NBMAs and serial lines, to achieve maximum efficiency (slide
  170.         11). To aid in this, Fred Baker thought that the Frame relay MIB
  171.         already had the provision to allocate particular sets of PVCs to
  172.         particular IP networks.
  173.  
  174.  
  175.  
  176.                                   [Page 3]
  177.  
  178.  
  179.  
  180.         People agreed that, in order to guarantee interoperability, a
  181.         document is needed to discuss the options for running OSPF over
  182.         Frame relay.  This document could also discuss ways of detecting
  183.         configuration errors (e.g., when some routers are configured for
  184.         NBMA support and others are configured to see the Frame relay as
  185.         serial lines).
  186.  
  187.         Osmund also discussed a possibility whereby routers connected to
  188.         a Frame Relay network could be grouped so that the groups were
  189.         fully interconnected (slide 12). It was thought that the NBMA
  190.         and Designated Router functions could be generalized to optimize
  191.         running OSPF over such a configuration, although exactly how to
  192.         implement this was unclear.
  193.