CURRENT_MEETING_REPORT_ Reported by John Moy/Proteon OSPF Minutes The OSPF Working Group met on Monday, July 29th at the Atlanta IETF. The following topics were discussed: OSPF trap MIB Rob Coltun led a discussion of his OSPF Trap MIB document. Briefly, this document began as a list of traps to help implementors debug their code. But Rob has now changed it to include only those traps that would be of use to a network manager. This has decreased the size of the Trap MIB significantly. Also, the Trap MIB was separated from the rest of the OSPF MIB in order to smooth the OSPF MIB's standardization path (traps are still somewhat controversial). It was decided that the following changes should be made to the Trap MIB document. After it is updated, the document will then be submitted to the Network Management Directorate. o The ospfIfStateChange and ospfVirtIfStateChange traps will only occur when either a) the new interface state is one of the terminal states (``DR'', ``Backup'' or ``Other'') or b) the interface state regresses (e.g., goes from ``DR'' to ``Down''). o The ospfNbrStateChange and ospfVirtNbrStateChange traps will only occur when either a) the new neighbor state is one of the terminal states (``2-Way'' or ``Full'') or b) the neighbor state regresses (e.g., goes from ``2-Way'' to ``1-Way''). o A new authentication failure trap will be created, splitting off from the existing ospfConfigError trap. This is because for net- works that are on the boundary of two ASes, authentication failures may be configured intentionally in order to separate two OSPF domains. o The reasons for the ospfRxBadPacket trap will be enumerated, just as the is currently done for the ospfConfigError trap. o The ospfOriginateLSA trap will not be invoked for simple refreshes of LSAs (which happen every 30 minutes), but instead will only be invoked when an LSA is (re)originated due to topology change. o The ospfMaxAgeLSA trap will only be invoked for those LSAs that the router itself ages to MaxAge (either normally or prematurely). It will not be invoked when the router receives a MaxAge advertisement from a neighbor. 1 o The ospfFreeLSA trap will be removed, since its functionality is (pretty much) identical to that of the ospfMaxAgeLSA trap. Not so stubby areas Next, Vince Fuller led a discussion of the proposed new ``not so stubby area'' option for OSPF. Briefly, the intent of this option is to create a new type of area (the ``not so stubby area'' or NSSA), which would not receive type 5 external LSAs from the backbone (and so would have a small database size), but would be allowed to itself originate a small number of external advertisements for distribution to the backbone. This would allow small RIP clouds to be hung off of the NSSAs. Vince Fuller and Rob Coltun are writing a document defining NSSAs. The intent is to add them in a backward compatible way to OSPF Version 2. As far as mechanisms for implementing NSSAs, there were two competing proposals, each differing on how the NSSA would represent the externals it exports to the backbone. o Option 1. The externals would be originated as regular type 5 LSAs. Flooding of type 5s between an NSSA and the backbone is unidirectional. Type 5s can be flooded from NSSAs to the backbone, but not vice versa. Advantages: 1) No conversion of the LSA would be necessary at the area border routers connecting the NSSA to the backbone. Disadvantages: 1) There would no longer be a global type 5 database. In fact, the type 5 database in the area border routers connecting the NSSAs to the backbone would be split into several pieces: one for each NSSA, and one for those type 5s originated by the backbone. Maintaining this split may prove difficult. o Option 2. The externals would be originated as a new LSA type (call it type 6 LSAs). The flooding of type 6 LSAs would be restricted to a single NSSA. The area border routers connecting the NSSA to the backbone would, in essence, convert the type 6 to a type 5 for distribution to the backbone. Advantages: 1) the type 5 database remains intact. In addition, the flooding of type 6s is similar to the flooding of all other LSAs that are specific to a single area (i.e., type 1-4s). Disadvantages: 1) The ``conversion'' of type 6s to type 5s in the 2 border routers may be fairly complicated (editor's note: at lunch Rob Coltun pointed out that the conversion could be made trivial by requiring that all type 6s be originated with forwarding addresses). 2) When there are multiple area border routers connect- ing the NSSA to the backbone, multiple type 5 LSAs may be produced for a single type 6 LSA. It was thought that this could be overcome by an election algorithm, if desired. Vince and Rob are going to further weigh the two approaches and then document their conclusions. Non-broadcast Networks Several people have noticed that OSPF's non-broadcast support could be made more robust in the face of misconfiguration, and that the amount of configuration (especially address translations) could be reduced by using some of the mechanisms in Paul Tsuchiya's SMDS routing and addressing internet draft (like ARP servers). We attempted to find some- one to write a document discussing these issues, but have as yet been unsuccessful. Joint Session with BGP Working Group We also met in a joint session with the BGP Working Group, where we reviewed Kannan Varadhan's document on BGP and OSPF interaction. Kannan's document give rules for exporting OSPF routes to BGP, importing BGP routes into OSPF, and defines how to set the OSPF external route tag in a vendor-independent manner. It also mandates that the OSPF router ID and the BGP router ID be set identically, and explains the circumstances where OSPF and BGP forwarding addresses should be used. Attendees Nagaraj Arunkumar nak@3com.com Jim Beers beers@nr-tech.cit.cornell.edu Tom Benkart teb@saturn.acc.com Nelson Bolyard nelson@sqi.com Scott Brim swb@nr-tech.cit.cornell.edu Henry Clark henryc@oar.net Rob Coltun rcoltun@ni.umd.edu Dave Cullerot cullerot@ctron.com Dino Farinacci dino@cisco.com Dennis Ferguson dennis@canet.ca Arlan Finestead arlanf@ncsa.uiuc.edu Vince Fuller vaf@stanford.edu Robert Griffioen Jeffrey Honig jch@nr-tech.cit.cornell.edu Phani Jujjavarapu phani@cisco.com Mark Lewis mlewis@telebit.com Joshua Littlefield josh@cayman.com 3 Brian Lloyd brian@telebit.com April Merrill Merrill@dockmaster.ncsc.mil Greg Minshall minshall@wc.novell.com John Moy jmoy@proteon.com Andy Nicholson droid@cray.com Karen O'Donoghue kodonog@relay.nswc.navy.mil Norman Patty Joe Peck peck@ms1.pa.dec.com Jason Perreault perreaul@interlan.interlan.com Roxanne Streeter streeter@nsipo.nasa.gov Mike Truskowski truskowski@cisco.com Brian Wheeler wheeler@mbunix.mitre.org 4