2.5.9 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 27-Oct-00


John Moy <john.moy@sycamorenet.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>

Routing Area Advisor:

Rob Coltun <rcoltun@redback.com>

Mailing Lists:

General Discussion:ospf@discuss.microsoft.com
To Subscribe: ospf-request@discuss.microsoft.com
Archive: http://discuss.microsoft.com/archives/ospf.html

Description of Working Group:

The OSPF Working Group will develop and field-test an SPF-based Internal Gateway Protocol. The specification will be published and written in such a way so as to encourage multiple vendor implementations.

Goals and Milestones:

Jun 96


Complete OSPF for IPv6 specification and submit to IESG for consideration as a Proposed Standard.

Jun 96


Document current usage, update OSPFv2 and submit to IESG for consideration as a Standard.

Dec 96


Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard.

Dec 96


Submit Internet-Draft on ISPF extensions of IPv6 to IESG for consideration as a Proposed Standard.

Jun 97


Update OSPF for IPv6 based on implementation experience, and submit to IESG for consideration as a Draft Standard.



Gather operational experience with the OSPF protocol and submit the document as an Informational RFC.



Develop multiple implementations, and test against each other.



Obtain performance data for the protocol.



Design the routing protocol, and write its specification.



Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC.

Jun 98


Submit OSPF for IPv6 to IESG for consideration as a Standard.


Request For Comments:






Experience with the OSPF Protocol



OSPF Protocol Analysis



The OSPF NSSA Option



Guidelines for Running OSPF Over Frame Relay Networks



OSPF Database Overflow



Extending OSPF to Support Demand Circuits



OSPF Version 2 Management Information Base



IP Forwarding Table MIB



OSPF Version 2



OSPF Standardization Report



The OSPF Opaque LSA Option



OSPF for IPv6



OSPF over ATM and Proxy PAR

Current Meeting Report

The OSPF Working Group met at the 49th IETF in San Diego, from 1300-1500 on Wednesday December 13, 2000. There were a couple problems with the way the Working Group meeting was run this time. First, due to a misestimation of attendance, the room was too small and a number of people had to be turned away due to fire regulations. Second, we mistakenly deviated from the agenda and due to lack of time Sira Panduranga Rao was unable to present his "Detecting Inactive Neighbors over OSPF Demand Circuits" (draft-ietf-ospf-dc-00.txt). His slides will however be included in the proceedings, and people are encouraged to look at them.

The meeting began with some administrative trivia. Two OSPF I-Ds have recently completed WG Last Call and are now in the hands of the IESG (draft-ietf-ospf-stub-adv-02.txt as Informational, draft-ietf-ospf-nssa-update-09.txt as a Proposed Standard). Three other I-Ds will be entering Last Call after the meeting (draft-ietf-ospf-abr-alt-03.txt as Informational, draft-ietf-ospf-shortcut-abr-02.txt as a Proposed Standard, and draft-pillay-esnault-ospf-flooding-02.txt as Informational). The OSPFv2 MIB is still having trouble with the MIB police, and the status of the OSPFv3 MIB was unknown, but the hope was that both are almost complete.

The following presentations were then given, with questions from the audience prefixed by "Q:".

1. Alex Zinin briefly presented "Alternative OSPF ABR Implementations", draft-ietf-ospf-abr-alt-03.txt. He said that the document accurately reflects current cisco router behavior, but that there was no intent to keep cisco behavior in synch with the document in the future. Q: Does this reduce the value of publishing the document as an Informational RFC?

2. Alex reminded people about the contents of "OSPF Shortcut ABR", draft-ietf-ospf-shortcut-abr-02.txt. It is a proposal to calculate efficient inter-area paths without the need for virtual link configuration.

3. Don Fedyk presented "Multiple Metrics for Traffic Engineering with IS-IS and OSPF", draft-fedyk-isis-ospf-te-metrics-01.txt. This draft had already been presented in the TE and IS-IS Working Groups. It proposes to introduce 3 optional metrics, that can be used instead of the current single TE metric when calculating paths of LSPs; the main desire is to be able to calculate paths on delay. Service providers say this is useful. The optional metrics were left undefined for flexibility, similar to DiffServe codepoints. When presented in the IS-IS WG, questions centered upon defining whether the metrics were additive, and what happens if some links don't specify some of the metrics. Q: Does this infringe the IGRP patent? A: No, that patent is specific to datagram routing. There was some debate on explicitly defining the metrics, especially delay. In general, the service providers seemed to be against definition, while some of the equipment manufacturers seemed to be in favor. Since LSPs are source routed, confusion as to metric meaning is not harmful. Some metrics, such as delay, can be calculate automatically by devices. Do we want to get involved in defining what delay actually is; for example, is it the sum of transmission and propagation delays? Q: How would these additional metrics be configured in a router interface? Maybe metrics should at least be designated as to whether they are min/max/additive? Question for the Routing ADs, who unfortunately weren't able to get into the room: How are TE metrics and their type codes being standardized in the IETF? (After the meeting, Rob Coltun said that metric standardization was to be done by the CCAMP WG).

4. Francois Le Faucheur presented "Extensions to OSPF for Diff-Serv-aware MPLS Traffic Engineering", draft-lefaucheur-diff-te-ospf-00.txt. This work was also presented in varying forms to the TE, MPLS and IS-IS Working Groups. It proposes to advertise unreserved bandwidth by class type, so that LSP paths can be calculated separately for each class type. The example given is EF traffic, which must be limited to some fixed percentage of the link. There are 4 class types, and 8 preemption levels, but instead of advertising 32 bandwidths a compression scheme is used to avoid advertising unused preemption levels. If class types are not listed for a link, they are considered unsupported. Q: How can this document become an OSPF WG item, when draft-katz-yeung-ospf-traffic-03.txt is not? A: We make any I-D a WG item if the author asks, but the katz-yeung draft is an oversight, and we will work with the authors to have it published as a Proposed Standard.

5. Alex briefly outlined "Guidelines for Efficient LSA Refreshment in OSPF", draft-ietf-ospf-refresh-guide-01.txt. This document lists many ways to spread out the flooding of LSA refreshes, and presents the method used in Zebra in detail. Alex would like this eventually published as an Informational document. John Rickey from Lucent said that his simulation results indicated that randomizing the first LSA refresh was not enough. He attributed this to the fact that a router reoriginates its router-LSA many times upon restart, and said that he had developed a different refresh algorithm.

6. A simulation of Alex' refresh draft and of the refresh specified in RFC 2328 was presented. This work was done as a Masters project at U. Ottawa. It was implemented in SDL, which looks like flowcharts. Results of the simulation indicated that the Zinin refresh draft did disperse LSAs. It was proposed to add the simulation results and the SDL code as an appendix to draft-ietf-ospf-refresh-guide-01.txt. Q: Does the simulation boot all the routers at once? A: Yes. It was agreed to rerun the simulation to reboot the routers randomly.

7. Alex presented "Flooding optimizations in link-state routing protocols", draft-ietf-ospf-isis-flood-opt-00.txt. John Moy claimed that reordering resulting from the load sharing over multiple links could break the flooding, and that to fix it you would have to use something like OSPF's cyptographic authentication or TCP to reimpose an ordering. Detailed discussion was taken offline.

8. John presented "Flooding over parallel point-to-point links", draft-ietf-ospf-ppp-flood-00.txt. He said that he developed this proposal as an alternative to Alex' proposal. He said that he was going to fix the problem of advertising link costs by updating the I-D to advertise a single router-to-router link with the smallest cost of any of the 2-way links. Q: Does this proposal break the OSPF TE proposals? A: No, both katz-yeung and link bundling advertise their own topologies. Q: Could this draft be merged with Alex' draft. A: No, because the load sharing issue is too big a difference. Curtis said that if you just consider links having the same MTU and cost, then the draft gets simpler. Alex said that the proposal breaks link-local Opaque-LSAs on point-to-point links, and that the advertisment of a single router-to-router link could also be retrofitted into his proposal.

9. Alex presented his three drafts for non-disruptive OSPF router restart (draft-ietf-ospf-lls-00.txt, draft-ietf-ospf-oob-resync-00.txt, draft-ietf-ospf-restart-00.txt). These drafts change OSPF Hello processing and Database Exchange to allow a restarting router to remain on the forwarding path. This proposal generated heated discussion. There was widespread support for non-disruptive restart functionality. Some people mentioned hot standby control processors as an alternative; Alex wanted a mechanism that would work with currently deployed hardware. Alex also wanted a scheme that didn't depend on new line card software, and so rejected the idea of continuing to send the last hello. Several people indicated that they thought a simpler solution must be possible. John reiterated his comment to the list that intentionally keeping an unsynchronized router on the forwarding path was a bad idea. Other people argued that while non-disruptive restart was important, the current proposal was too dangerous. Alex argued that the group should accept the proposal since similar work was accepted without controversy by the BGP group (IDR); other people disputed that argument. A representative of a service provider who was a strong proponent of the functionality said that he wanted a knob to turn it off, and that he was only going to use it for software upgrades.

Meeting minutes taken by John Moy.


Detecting Inactive Neighbors Over OSPF