2.5.9 Open Shortest Path First IGP (ospf)

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

Chair(s):

John Moy <jmoy@pop.tiac.net>

Routing Area Director(s):

Rob Coltun <rcoltun@lightera.com>

Routing Area Advisor:

Rob Coltun <rcoltun@lightera.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

RFC1586

 

Guidelines for Running OSPF Over Frame Relay Networks

RFC1587

PS

The OSPF NSSA Option

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

Current Meeting Report

The OSPF Working Group met for a single session at the 44th IETF in Minneapolis, from 1545-1800 on 3/16/99. Minutes of the working group session follow, as recorded by John Moy.

1. OSPF Extensions for Traffic Engineering.
- There were two proposals in this area, which dealt with the encoding of traffic parameters in LSAs, in line with the similar parameters introduced into IS-IS in <draft-ietf-isis-traffic-00.txt>. Before the WG meeting, the two OSPF proposals (<draft-yeung-ospf-traffic-00.txt> by Derek Yeung of Cisco, and one that had been sent to the list by Dave Katz of Juniper) were merged, and Dave presented the resulting proposal.
- The encoding of traffic parameters was kept flexible, because traffic engineering is in its infancy and will probably evolve. Self-padding TLVs were used. Right now only transmit parameters are advertised, but receive parameters will be added in the future.
- It was agreed that there would be a separate "traffic engineering" LSA for each link, in order to keep the LSAs small. Dave's goal is to reach agreement on the encodings as soon as possible. It has been useful to advertise an IP address for each router for traffic engineering purposes; this will be done in the standard OSPF router-LSA.

2. Additional Traffic Engineering Extensions.
- Walt Wimer of FORE presented his draft <draft-wimer-ospf-traffic-00.txt>. Additional traffic parameter encodings were proposed for link propagation delay and packet loss per diffserv codepoint. Curtis Villamizar said that how often these parameters are flooded should be specified.

3. Cheryl Sanchez of Avici proposed several other traffic parameters to be advertised within OSPF: the current fault protected bandwidth reservation (for fast reroute), current link utilization, and the probability of packet drops. It was mentioned that instead of bringing these proposals for new traffic parameters to all the concerned working groups, that maybe a new working group be formed to keep track of Traffic Engineering concerns.

4. Multipath Issues in Unicast and Multicast.
- Dave Thaler of Microsoft presented <draft-thaler-multipath-02.txt>. While not particular to OSPF, this should be of general interest to OSPF developers. The goal of the draft is to fix broken multipath implementations, but not to try to enumerate all possible next hop selections. Three sample multipath forwarding algorithms are provided in the draft; their applicability depends on whether the implementation is keeping flow state.
- The draft applies to both unicast and multicast. PIM could use these algorithms to spread out load based on multicast group. MOSPF could do the same.

5. OSPF Optimized Multipath.
- Curtis Villamizer of UNNET gave an update on <draft-ietf-ospf-omp-02>. Examples in the draft are now simulated, see http://engr.ans.net/ospf-omp/worked-example.html. Simulations are now being run on UUNET's real topology. OSPF-OMP did better than a simple LSP layout strategy, and converged faster than MPLS-OMP (although it required carefully configured link metrics). Curtis is interested in experimenting with more sophisticated LSP layout algorithms.
- OSPF-OMP parameters have been experimentally set; some of them (flooding and load adjustment timers) can cause instability if set inconsistently. Which, if any, parameters need to be set the same in all routers? If an implementation does not keep track of all equal-cost paths, OSPF-OMP will still work but not as optimally. If traffic parameters are not reported for some links those links are assumed to be completely unloaded.
- Curtis is looking for implementations. He believes that there are no implementations yet due to a combination of factors:

6. The OSPF NSSA Option.
- Pat Murphy of the US Geological Survey gave a review of the major points of <draft-ietf-ospf-nssa-update-07.txt>, including the configuration of the translating router(s), advertising of the default when summary-LSAs are inhibited, and the "P-bit paradox". The draft will now undergo minor editing and will then go to working group last call on the way to replacing RFC 1587.

7. OSPF ABR behavior.
- John Moy presented Alex Zinin's (AMT Group) document <draft-ietf-ospf-abr-behavior-00.txt>, which contains two proposals for optimizing inter-area traffic. The first, called "short-cut ABR", allows area border routers to examine all areas' summary-LSAs (instead of just area 0's). A rule on origination of summary-LSAs prevents bad convergence behavior (such as counting to infinity) in the inter-area routing. The second option, called "transit router", is based on behavior currently implemented in the cisco and IBM routers. In this option, a router acts as an area border router only if it has an active attachment to the backbone area. Acee Lindem wanted the definition of area border router changed accordingly, but John Moy thought that it was too late to make such a change to the base OSPF protocol. It was pointed out that aggregation still gets in the way of optimal inter-area routing.

8. OSPF Multiple Area Links.
- Pat Murphy ended the meeting with a few thoughts on <draft-ietf-ospf-mlinks-00.txt>, which among other things is capable of supporting multiple areas over an unnumbered point-to-point link.

Slides

OSPF ABR Behavior
Multipath Issues In Unicast and Multicast