HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:03:59 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 09 Dec 1992 04:35:00 GMT ETag: "3dddcc-2179-2b257774" Accept-Ranges: bytes Content-Length: 8569 Connection: close Content-Type: text/plain Editor's Note: Minutes received 7/31 CURRENT_MEETING_REPORT_ Reported by John Moy/Proteon Minutes of the Open Shortest Path First IGP Working Group (OSPF) The OSPF Working Group met at the July 1992 IETF in Boston. The Minutes from that meeting follow. The meeting began with a review of the four documents that are currently be considered for publication by the Working Group: 1. The updated OSPF V2 specification. This will supersede RFC 1247. Unfortunately, the document was not available prior to the meeting. (A limited number of paper copies of the updated specification were made available to implementors, and the specification was made available for anonymous ftp after the meeting.) An excerpt from the document briefly detailing the changes was handed out, and the changes (all backward- compatible) were discussed. It was also decided to make one additional change: it will now be possible to specify a set of area address ranges that will not be advertised in summary-LSAs. This will enable a network administrator to hide certain networks within their local areas. This change has already been implemented by some vendors. 2. The updated OSPF V2 MIB. This will supersede RFC1253. Fred Baker outlined the proposed changes. It was also decided to make additions for the multicast routing extensions and the new NSSA area option. An addition to the Area Range Group was also made for the above ``hidden network'' feature. An additional request for a network mask in the new external-LSA table entries was not acted upon. 3. The OSPF Trap MIB. Rob Coltun led the discussion. There was some question whether an additional error code should be added for receiving Illegal-LSAs. It was decided that this would probably already show up as retransmissions by the faulty sender, and as such was unnecessary. It was also decided to have the ospfLsdbApproachingOverflow trap occur at a configurable database size, instead of 90 percent of the maximum (as stated in the draft). 4. The OSPF NSSA option. Rob Coltun spent some time explaining how they work, spending time on the translation between type-7 and type-5 LSAs, and how you could distinguish a ``local'' type-7 default from one that can be translated into a global type-5 default. No changes were made to this document. Osmund deSouza presented a proposal for running OSPF over Frame relay. There was general agreement on the problem: Frame relay is in general not full-mesh connected, and the network administrator sometimes wants to assign different costs to different PVCs. For these reasons, OSPF's 1 non-broadcast model is not directly applicable. There was also general agreement on the solution: instead of treating the connection to Frame relay as a single OSPF interface, define an OSPF interface as some collection of PVCs. There was a long discussion of how to represent this in terms of MIB II and the OSPF MIB. It was decided that Osmund et. al., with the help of Fred Baker, would rewrite their present document more along the lines of a usage document. With this document in hand, it would be hoped that equipment from different vendors would be able to interoperate using OSPF over Frame relay. John Moy presented an alternative model for running OSPF over Frame relay, where there would be a single interface to the frame relay net and a) neighbors would be discovered dynamically using Inverse ARP b) OSPF Hellos would be used to build a spanning tree among Frame relay connected routers, for purpose of update distribution (database synchronization) c) by default, only these spanning tree links (adjacencies) would be included in router-LSAs and d) to get better routing across the Frame relay, more PVCs could be included in the router-LSAs or (not as good) a variant of short-cut routing could be used. John's main reason for preferring this approach is that it didn't need a human to configure it, and that it was optimal in terms of routing traffic. This proposal was not generally well received, being characterized as either too complicated or too different than current practice. John said that he would write it up anyway if he had the time. John Moy presented a proposal for dealing with OSPF Database Overflow. In this proposal, only the number of type-5 LSAs would be limited. The reasoning being that these constitute a majority of the database in places like the NSF regionals. A limit for the number of these LSAs would be set identically in each of these routers, either via SNMP or negotiated in a new LSA type or in OSPF Hellos. Then, when the limit is reached in a router it a) won't accept any more and b) will flush all its self-originated type-5 LSAs, refusing to originate any more. The claim is that this logic produces an identical database in all routers, with less than the configured maximum number of type 5 LSAs, no continual retransmissions, and all internal routing intact. Enhancements to this scheme could involve limiting other LSA types (e.g., summaries), and to begin again to originate type-5 LSAs after a random time lag to automatically deal with temporary overflow. John said that a similar scheme has been used in Proteon routers for several years. The proposal was characterized by some Working Group members as being like congestion control, and some desire for an additional congestion-avoidance-like mechanism was expressed. Some people also requested a way to prioritize the order in which excess advertisements are flushed (e.g., you might want to flush the default routes last). John promised to sort through the enhancements and publish a coherent Internet Draft. Rob Coltun ended the meeting with a quick discussion on how hierarchical routing information might be injected into OSPF, in order to support any of the schemes for IPV7. 2 Attendees J. Allard jallard@microsoft.com William Babson bill@penril.com Dennis Baker dbaker@wellfleet.com Fred Baker fbaker@acc.com John Ballard jballard@microsoft.com Ken Benstead kbenstead@coral.com Geetha Brown geetha@decvax.dec.com Steve Buchko stevebu@newbridge.com Greg Celmainis gregc@newbridge.com Frank Chen frankc@casc.com Dean Cheng dean@sun2.retix.com Robert Ching natadm!rching@uunet.uu.net Chris Chiotasso chris@artel.com Henry Clark henryc@oar.net Rob Coltun rcoltun@ni.umd.edu Jim Comen comenj@interlan.interlan.com Michael Davison davison@cs.utk.edu Osmund de Souza osmund.desouza@att.com Dino Farinacci dino@cisco.com AnneMarie Freitas afreitas@microcom.com Vince Fuller vaf@stanford.edu Kelly Furlong kelly@kyle.ksc.nasa.gov Der-Hwa Gan dhg@nsd.3com.com Ian Heavens ian@spider.co.uk Jeffrey Honig jch@nr-tech.cit.cornell.edu Steven Hubert hubert@cac.washington.edu Ronald Jacoby rj@sgi.com Dwight Jamieson djamies@bnr.ca Dan Jordt danj@nwnet.net John Krawczyk jkrawczy@wellfleet.com Alan Kullberg akullber@bbn.com Whay Lee whay@merlin.dev.cdx.mot.com Anthony Lisotta lisotta@nas.nasa.gov Robin Littlefield rlittlef@wellfleet.com John Moy jmoy@proteon.com Erik Nordmark nordmark@eng.sun.com Benny Rodrig 4373580@mcimail.com Manoel Rodrigues manoel_rodrigues@att.com Henry Sanders henrysa@microsoft.com Hellen Sears sears@interlan.interlan.com Martha Steenstrup msteenst@bbn.com Linda Tom toml@interlan.interlan.com Kannan Varadhan kannan@oar.net Scott Wasson sgwasson@eng.xyplex.com Luanne Waul luanne@wwtc.timeplex.com Honda Wu natadm!honda@uunet.uu.net 3