This is a rough draft - Megan 04/06/92 Hi. Here are the minutes of the last OSPF Working group meeting. I have referenced the handwritten slides that people presented; unfortunately to see them you'll have to get a copy from the proceedings. It reads pretty well without them though... John ------------------------ cut here ---------------------------------- OSPF WG minutes: March 92 meeting The OSPF Working Group met at the March 1992 IETF in San Diego. The minutes from that meeting follow. The meeting began with an announcement that IP multicast has been assigned an 802.5 functional address. This affects OSPF over 802.5, since many OSPF control packets (Hellos, etc.) are sent as IP multicasts. The functional address assignment will be documented in a short RFC, probably written by Steve Deering. It was suggested that to aid in the transition from the 802.5 broadcast address to the new functional address, a configuration knob be provided in OSPF implementations to select between broadcast/functional address. In any case, by the principle of "be liberal in what you receive", you should not reject a packet whose link level destination is the broadcast if you are instead expecting the functional address (this would enable a staged transition to the functional address, where you first enable reception of the functional address, and then in some future release start sending it). There are now a number of OSPF documents that will soon be ready for publication as RFCs: reissues of the base spec and the OSPF MIB, the OSPF Trap MIB, and the OSPF NSSA document. It is likely that these documents will want to reference each other, which may cause some logistical problems since you can't reference Internet Drafts (maybe they'll have to be issued as a set). In any case, it was decided to delay the publication of these documents until there were at least two interoperable implementations. During the main part of the meeting, the following issues were discussed: o We reviewed proposed changes to the base OSPF spec (RFC 1247). These changes are: a fix to a bug found in certain virtual link configurations, updating the TOS representation to include the new monetary cost bit, making summarization of routes into stub areas optional and an optimization to summarizing routes into transit areas. At the previous IETF a different fix to virtual link problem was discussed and rejected due to its complexity. The present fix, suggested independently be several people, is much simpler. Part of the fix involves removing the ability to assign a cost of LSInfinity to router interfaces. The fans of Strong TOS (e.g., Milo and John Lekashman) were against this. John Moy was assigned the action item of further explaining why LSInfinity was a problem, and then negotiating with Milo and John. Fred Baker also mentioned that he had come across a situation where he wanted to condense inter-area routing information (not just intra-area, as specified in the current [Page 1] spec), but that the provision making summarization into stub areas optional would serve just as well. The proposed changes to RFC 1247 will be published shortly as an Internet Draft, followed by a revised version of the OSPF spec. All changes are backward compatible; there will be no need to increase the OSPF version number. o Rob Coltun presented a collection of backward-compatible additions to the OSPF MIB. These additions included three variables to deal with OSPF Database Overflow: LSDBHiWater (read-only; the largest number of LSAs that have ever been in the router's database), LSDBOverflowWarning (read/write; when the number of LSAs hits this number a trap is generated) and LSDBLimit (read/write; when the number of LSAs hits this number the router takes further action to limit the size of the database as specified in a document to be written by John Moy). Also, a new table for type 5 external-LSAs is to be included, since in the current MIB it is not clear in which area ospfLsdbTable these LSAs should be reported. Fred Baker explained that, in order to be backward compatible, it would still be legal to report the type 5 externals LSAs in the old ospfLsdbTable. It was also noted that there should be two new ospfLsdbType values: 6 (for the group-membership-LSAs) and 7 (for the LSAs used by NSSA areas). In addition, since the interface cost LSInfinity is being removed, the comment in the ospfIfMetricMetric entry ("The value FFFF is distinguished to mean 'no router via this TOS'") should be removed. Jeff Honig brought up a list of MIB variables that were named inconsistently. According to Fred Baker, we do not have to maintain the ascii text representation of MIB variables to qualify for backward-compatibility, even though this may be an inconvenience to certain network management stations. Rob, Fred and Jeff are to go though the MIB to see which variables warrant renaming. o Rob Coltun summarized the state of the OSPF Trap MIB (see Slide 2) which is very near to being finalized. There was some discussion on the best strategy for inhibiting traps when a router first starts, with the arguments for and against inhibiting traps on a per-interface basis being rehashed once again. o Jeff Honig brought up the issue on how the OSPF MIB could handle multiple instances of OSPF running in the same box. While there [Page 2] is a straightforward technical solution to this problem (basically adding another index to all the MIB's tables), this is not backward-compatible and was viewed by several people as making the MIB overly complicated. Fred Baker suggested that this was a larger issue than just for OSPF, and suggested that we pass the problem (namely, how to monitor several instances of a protocol) on to the network management working group. o Rob Coltun and Vince Fuller have completed a document describing the OSPF Not-so-stubby-area (NSSA) option, adding a motivational section to the outline that was presented the previous meeting (Santa Fe), and completing the technical details. Rob presented an overview of the NSSA support, together with some of the more non-obvious details (see slide 3). Basically, NSSAs are a new type of area, similar to OSPF stub areas in that they do not handle type 5 external-LSAs (and so routers internal to these areas require less resources). However, NSSAs are capable of importing external information of their own, which will be converted to normal type 5 LSAs at the NSSA boundary. This enables, for example, RIP clouds to be hung off of NSSA areas. Discussion centered upon whether we should be multiplexing several functions onto a single OSPF options bit (now that they are getting scarce), and the correct way to model the translation of external information that takes place at the NSSA boundary. o Rob Coltun and Jeff Honig presented a proposal for another new OSPF option, which they called the PRI (Peripheral Router Interconnect) option (see Slides 4-7). This would provide a way to configure a set of distinguished OSPF routers, which would automatically discover each other and then be able to exchange additional information formatted as new LSA types. Jeff Honig explained an application of this whereby the PRI routers could exchange AS path information, obviating the need for IBGP. Rob and Jeff intend to write this up in more detail. o Osmund deSouza led a discussion on how to run OSPF over Frame relay (slides 9-12). One concern was that, since in real Frame relay networks you are unlikely to have full mesh connectivity for PVCs, the NBMA model does not apply. In these cases, the Frame relay would have to be treated as a collection of point- to-point links. A number of people thought that it might be possible to model Frame relay as a collections of some number of NBMAs and serial lines, to achieve maximum efficiency (slide 11). To aid in this, Fred Baker thought that the Frame relay MIB already had the provision to allocate particular sets of PVCs to particular IP networks. [Page 3] People agreed that, in order to guarantee interoperability, a document is needed to discuss the options for running OSPF over Frame relay. This document could also discuss ways of detecting configuration errors (e.g., when some routers are configured for NBMA support and others are configured to see the Frame relay as serial lines). Osmund also discussed a possibility whereby routers connected to a Frame Relay network could be grouped so that the groups were fully interconnected (slide 12). It was thought that the NBMA and Designated Router functions could be generalized to optimize running OSPF over such a configuration, although exactly how to implement this was unclear.