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