CURRENT_MEETING_REPORT_ Reported by John Moy/Proteon Minutes of the Open Shortest Path First IGP Working Group (OSPF) The OSPF Working Group met Tuesday November 19, 1991 at the Santa Fe IETF. The Minutes of the Working Group meeting follow. In addition, at this IETF work was performed (and decisions were made) in other working groups affecting OSPF. This related work is summarized below in the liaison section. 1. Liason With Other Working Groups o In the Open IESG meeting, it was announced that the IAB had approved the OSPF Applicability Statement, which recommends the use of OSPF as the Common IGP. It is expected that the Applicability statement will be published as an RFC. o The wording of the router requirements document now reads: if a router implements dynamic routing, it must implement OSPF (as an aside, it also must implement RIP). Router requirements has also made TOS in OSPF optional (this was part of a more general discussion of whether further subsets of OSPF are possible and/or useful, which was continued at the OSPF Working Group meeting; see Section 2.5 below). The router requirements Working Group has also asked that the behavior of OSPF in the face of database overflows be written down. Finally, an IP Forwarding Table MIB has been defined allowing network management stations to dump equal-cost routes, and routes that depend on TOS (both of which are possible with OSPF). o The BGP Working Group has been working on a document specifying the interaction between BGP and OSPF. A first draft of this document, written by Kannan Varadhan of OARNet, had been published as an Internet Draft before the Santa Fe IETF. At the IETF the sections describing route exchange, the setting of BGP IDs and OSPF Router IDs, and the setting of the BGP NEXT_HOP attribute and the OSPF forwarding address were pretty much agreed upon. The setting of the tag field in type 5 AS external LSAs was more controversial, and several different proposals were floated. An updated Internet Draft should appear shortly. 2. Working Group Minutes The following items were discussed in the Working Group session. All items on the Agenda were covered, except for a planned 1 discussion of OSPF's non-broadcast network support (which is a hot topic currently because of all the activity in the IPLPDN group). (a) A Problematic Virtual Link Configuration A handout was provided describing a configuration of virtual links that was found to create routing loops. This configuration was discovered during the last round of OSPF testing, immediately prior to Interop '91. Basically, the problem arises because, in a virtual link's transit area, the area border routers may have a different view of routing than the area's internal routers. The current OSPF specification tries to deal with this by have the endpoints of a virtual link run an extra computation: the ``resolution of virtual next hops'' described in Section 13.3 of the spec. However, this is not enough to avoid loops in all configurations, as the handout showed. The handout also presented a fix to the spec, whereby any router bordering transit areas would a) keep track of all transit areas that are traversed on route to any particular destination and b) for such a destination, run the ``resolution of virtual next hops'' using summary links belonging to each of the traversed areas. It was generally felt that the handout's fix was too complicated. An alternative fix, involving less bookkeeping while potentially running the ``resolution of virtual next hops'' process on more destinations, was proposed. This simpler fix is being investigated. The handout, augmented with a discussion of the simpler fix, will be published as an Internet Draft. Eventually, a new (but backward-compatible) version of the OSPF specification will have to be published. Besides having a fix for the virtual link problem, it was proposed to at that time add the following: a) make the origination of summary-LSAs into stub areas optional and b) Add text describing how to avoid originating summary-LSAs into an area when you know that they will never be used (i.e., when the first hop for the destination belongs to the area itself; this is sort of equivalent to split horizon in a Bellman-Ford algorithm). (b) Proposed Changes to the OSPF MIB The following changes to the OSPF MIB were proposed. It is the intent that all these changes be backward-compatible with the present MIB: o Change the range of the ospfIfRtrDeadInterval, ospfIfPollInterval and ospfVirtIfRtrDeadInterval variables from 0-0xffffffff to 0-0x7fffffff. This is being done to make life easier for MIB compilers, realizing that it 2 doesn't really make any sense to set the variables higher than 0x7fffffff anyway. o Remove the TOSType definition from the OSPF MIB, and instead refer to a TOS definition in the new IP Forwarding Table MIB. o Add a separate table for type 5 AS externals, removing them from the current ospfLsdbTable. At the moment it is not clear just where in the ospfLsdbTable the type 5 AS externals should go. o Add type 6 (group-membership-LSAs) and type 7 (the new NSSA externals) LS types to the ospfLsdbTable. This will allow us to monitor the OSPF extensions (somewhat) from the base OSPF MIB. o Add a boolean to the Area Table allowing you to turn on or off the origination of summary-LSAs into stub areas. o Somehow figure out how to represent OSPF type 1 and type 2 metrics, and also the four level OSPF routing hierarchy (intra-area, inter-area, type 1 external and type 2 external) in the new IP Forwarding Table MIB. This may be done entirely with comments. There was an additional proposal on the table to clean up/rationalize the ascii names of some of the OSPF MIB variables. It was decided to ask the Network Management Directorate whether this would be too large a change to make at this time. (c) The OSPF Trap MIB Rob Coltun reported on the state of the OSPF Trap MIB. There are currently twelve traps: Interface state change (regular and virtual), Neighbor state change (regular and virtual), Configuration error (over real and virtual links), Receive bad packet (over regular and virtual links), Packet retransmission (over regular and virtual links), Originate LSA and MaxAge LSA. Each trap can be enabled and disabled separately. Trap origination is rate-limited, and traps are inhibited for the first 2*DeadInterval seconds after a router comes up. It was decided to add two more traps. The first indicates that the link state database has overflowed. The second indicates that the link state database is close to overflowing, because available resources having dropped below some configurable threshold (units of the threshold being number of LSAs). After making these additions, the document will be published as an Internet Draft. 3 (d) Current Proposal for OSPF NSSA Areas Rob Coltun presented the current proposal for OSPF NSSA areas. His viewgraphs will appear in the IETF proceedings. A brief summary of his presentation follows: o An NSSA area (Not so stubby area) is a new kind of area which does not process type 5 external LSAs (reducing memory resource requirements) but which can originate external routing information and pass it on to the rest of the OSPF system. For example, an NSSA area can be used where you wanted to use an OSPF stub area, but couldn't because hanging hanging off of the area was a RIP cloud. o External routes are originated into an NSSA area via a new link state advertisement: type 7 LSAs. The format of type 7 LSAs are identical to type 5 LSAs. However, type 7s are specific to a single NSSA area only. There will be a propagate bit in the type 7 LSA's Options field which indicates whether the type 7 LSA should be translated into a type 5 LSA at the NSSA border. Those type 7 LSAs which are to be translated MUST specify a forwarding address (this makes translation into type 5 LSAs simple, and also enables a simple already specified tie-breaking mechanism ensuring that only one border router does the translation). o Area border routers attached to NSSAs originate a type 7 LSA specifying the default route (with the propagate bit off) into the NSSA. This compensates for the fact that type 5 LSAs are not flooded into NSSAs. Also, to maintain the OSPF routing hierarchy area border routers attached to NSSAs must summarize the internal (intra-area and inter-area) OSPF routes into the NSSA (for OSPF stub areas this summarization is optional). Several other possible NSSA features were discussed, namely: a) allowing type 7 information to be collapsed (instead of directly translated) at NSSA boundaries and b) allowing selective reverse translation at NSSA boundaries (i.e., type 5 LSAs into type 7 LSAs for propagation into the NSSA). It was decided to leave both features outside the scope of the NSSA option. (e) Defining a Minimal Subset of OSPF We spent some time discussing whether it was useful to subset OSPF beyond simply making TOS optional. It was generally agreed that this would probably not be a commercially viable product, since the router would be limited to only certain places in the topology. However, it did appear that it might be viable for those products that naturally reside at the edge of the IP routing domain, for example, the Shiva FastPath box. 4 3. Action Items o Revise the OSPF specification with a fix for the virtual link problem [John Moy] o Revise the OSPF MIB [Fred Baker] o Publish the OSPF Trap MIB as an Internet Draft [Rob Coltun] o Document the NSSA option and publish as an Internet Draft [Rob Coltun and Vince Fuller] o Outline the possibilities for a minimal OSPF implementation [John Moy with help from Shiva and Cayman Systems]. o Document the OSPF response to database overflow [John Moy] Attendees Steve Alexander stevea@i88.isc.com Fred Baker fbaker@emerald.acc.com James Barnes barnes@xylogics.com James Beers beers@nr-tech.cit.cornell.edu David Bolen db3l@nis.ans.net Gregory Bruell gob@shiva.com Dean Cheng dean@sunz.retix.com Kenneth Crepea crepea@cisco.com John Damiano Kurt Dobbins dobbins@ctron.com Christine Hemrick hemrick@cisco.com Ronald Jacoby rj@sgi.com April Merrill abmerri@tycho.ncsc.mil Dean Morris morris@marvin.dec.com John Moy jmoy@proteon.com Thomas Pusateri pusateri@cs.duke.edu Manoel Rodrigues manoel.rodrigues@att.com Sharad Sanghi sharad@ans.net Stephen Shew sdshew@bnr.ca Richard Smith smiddy@pluto.dss.com Frank Solensky solensky@clearpoint.com Ravi Srinivasan ravi@eng.vitalink.com Yuan Wang natadm!ycw@uunet.uu.net Scott Wasson sgw@sgw.xyplex.com Osmund de Souza osmund.desouza@att.com 5