2.5.6 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

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.

Done

  

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

Done

  

Develop multiple implementations, and test against each other.

Done

  

Obtain performance data for the protocol.

Done

  

Design the routing protocol, and write its specification.

Done

  

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.

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC1246

 

Experience with the OSPF Protocol

RFC1245

 

OSPF Protocol Analysis

RFC1587

PS

The OSPF NSSA Option

RFC1586

 

Guidelines for Running OSPF Over Frame Relay Networks

RFC1765

E

OSPF Database Overflow

RFC1793

PS

Extending OSPF to Support Demand Circuits

RFC1850

DS

OSPF Version 2 Management Information Base

RFC2096

PS

IP Forwarding Table MIB

RFC2328

S

OSPF Version 2

RFC2329

 

OSPF Standardization Report

RFC2370

PS

The OSPF Opaque LSA Option

RFC2740

PS

OSPF for IPv6

RFC2844

E

OSPF over ATM and Proxy PAR

Current Meeting Report

The OSPF WG met at the 50th
IETF in Minneapolis, Wednesday 3/21 from 1300-1500.
The minutes of the meeting follow.

Two new WG Last Calls were announced: the OSPF for IPv6 MIB (draft-ietf-ospf-ospfv3-mib-04.txt) to Proposed Standard, and the Traffic Engineering Extensions to OSPF (draft-katz-yeung-ospf-traffic-04.txt), also to Proposed Standard. All future TE metric documents will be handled by the CCAMP or TE Working Groups, instead of OSPF.

In particular, the OSPF Extensions in Support of Generalized MPLS (draft-kompella-ospf-gmpls-extensions-01.txt) is being handed off to CCAMP.

Later a reminder was given to the room that the OSPF/BGP/IDRP interaction RFCs were in the process of being reclassified as Historic. People using those RFCs should contact the IESG, or run the risk of losing vendor support when the RFCs become Historic.

The following presentations were also given.

1. Simulation of draft-ietf-ospf-refresh-guide-01.txt
O. Monkewich
Simulations presented last meeting were updated to address comments: router start up was randomized, and more LSAs were used (random number between 1 and 100 originated by each router).
Simulates Alex' LSA refresh techniques draft versus standard RFC 2328 behavior. Simulation done in SDL (Specification Description Language). Result of simulation: Alex' draft works, and so does SDL. Problem with publishing model as appendix to Alex' draft, as SDL is graphical.
URL for the SDL model will be sent to the OSPF list.

2. Detecting Inactive Neighbors over OSPF Demand Circuits
draft-ietf-ospf-dc-01.txt
Abhay Roy
This draft is a bug fix for RFC 1793, which cannot detect when the OSPF process on the other end of a demand circuit terminates. John Moy made the following comments. Draft proposes two separate mechanisms, where only one is necessary.
Doesn't like limiting retransmissions, as that covers up software bugs. Likes probing with Link State Update, although response to a probe can be either a LS ack or a LS update.

3. Flooding over parallel point-to-point links
draft-ietf-ospf-ppp-flood-01.txt
J. Moy
Changes from last time: change router-LSA origination to preserve metric settings, and detect and destroy lingering adjacencies. Vijay Gill commented that flooding reduction was not a concern in his network, but was more concerned about creeping featurism adversely affecting router stability.
Q: Advantage of draft? A: Reduce control traffic load on routers and links. Other people said flooding reduction was desirable.
Q: How to resolve conflict with competing draft draft-ietf-ospf-isis-flood-opt-01.txt? A: IETF not too good with conflict resolution, usually resolved by either one side giving up or by the market.

4. Unnumbered OSPF Multiple Area Links
draft-ietf-ospf-mlinks-02.txt
P. Murphy
Pat reviewed his proposal for optimizing routing over unnumbered links in the presence of areas, by allowing the assignment of secondary areas to links.

5. OSPF Restart Signaling
draft-ietf-ospf-oob-resync-01.txt
draft-ietf-ospf-restart-01.txt
Abhay Roy
The changes from last time were that fail-safe measures were added: OOB synch stops when timer expires, timer to
KillNbr if synch doesn't start, and a config option to cancel restarts if routing table changes. They have working code the some customers are playing with.

6. Hitless OSPF Restart
draft-ietf-ospf-hitless-restart-00.txt
J. Moy
Proposal developed as alternative to draft-ietf-ospf-oob-resync-01.txt.
Discussion included the following points.
Several people think that trying a hitless restart after a crash is too dangerous. How do you verify valid forwarding state? Couldn't a crash corrupt almost anything? Another view: trying to recover from a crash is better than nothing, but wants knob to turn off recovery if "k" recoveries attempted in "n" seconds. John says neighbor can base decision to honor grace period on many things, including MAC address of restarting router. Sometimes crashes are in other software modules, making it safer to restart OSPF hitlessly. Maybe hitless support will simplify software support for redundant control cards? Vince Fuller prefers this restart proposal because it doesn't change database synchronization, which he views as dangerous.
Q: Is either proposal affected by doing Hello processing on forwarding cards? John: I don't think so, but I think Hello processing should be done on the control card.

Sense of the room was then taken by a raising of hands, with the following result:
1) people want hitless restart support
2) fewer, but still a significant number, wanted to be able to recover from a crash
3) most people preferred John's hitless restart proposal (draft-ietf-ospf-hitless-restart-00.txt)
4) people think hitless restart needs more work.

7. Prioritized Treatment of Specific IGP Packets
draft-ietf-ospf-scalability-00.txt
A. S. Maunder
Simulation indicates that flooding storms and routing calculations can delay hello processing long enough to destroy neighbor relationships, spreading network congestion. This will get worse as hello and routing calculation intervals are reduced, as advocated by draft-alaettinoglu-isis-convergence-00.txt. Solution is to prefer Hello packets. Authors also propose that LS acks and LSAs with bad news be preferred.
Q: Isn't this just an implementation issue, solved by using a higher priority thread?
Dave Oran: IS-IS specifies that Hellos are preferred. Others: Have tested 2 IS-IS implementations, they do prefer Hellos, and link stay up even if CPU 100%. Good discussion of implementation issues on IS-IS mailing list.
Q: Can diffserve codepoints be used to mark Hellos?
Dave: Marking not necessary, at least on input, where routers should be able to peer into packets and discard at line rate. Other people didn't like this "deep classification".

8. OSPF Floodgates
draft-ietf-ospf-floodgates-01.txt
P. Murphy
Pat presented his proposal to reduce flooding by dynamically enabling/disabling flooding on links as "floodgates" are open/closed.
Two separate cases, regular links and stub links.

9. Flooding Over a Subset Topology
draft-ietf-ospf-subset-flood-00.txt
J. Moy
John's proposal to reduce flooding by inhibiting adjacency formation on all but a subset of links. This is not rocket science, but standardizing behavior that has been implemented previously. Q: Could only certain LSAs (like TE LSAs) be flooded over the subset topology, using regular flooding for the rest?
Dave: In that case, subset could be a dynamically calculated spanning tree. This flooding not as robust as regular OSPF.

10. OSPF Type 5 to Type 7 Translation
ftp://noc.doi.net/ietf/draft-ietf-ospf-5to7-00.txt
P. Murphy (10 minutes)
Pat had a couple of minutes at the end of the meeting to present his proposal for summarizing type-5 LSA learned routes into NSSAs as type-7 LSAs. To make this work, Pat requests that developers of NSSA software set the P-bit in the NSSA router-LSAs.

Submitted by John Moy on 3-28-01

Slides

Explicit Marking and Prioritized Treatment of Specific IGP Packets...