2.4.8 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-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 48th IETF on Monday, July 31 from 1530-1730. The meeting began with mention of the last calls that can be expected in the near future: the OSPFv3 MIB to proposed, the revised OSPFv2 MIB (standards level to be negotiated with NM ADs) and the NSSA Update document (Proposed). The following presentations were then given.

1) Francois Le Faucheur presented "extensions to OSPF for Diff-Serv TE" <draft-lefaucheur-diff-te-ext-00.txt>. This makes the link bandwidth allocation to DiffServ classes visible to routing, so that, for example, paths for EF (expedited forwarding) traffic can be restricted to those links having a small percentage of existing EF traffic. Requirements for Diffserv-aware MPLS TE are being defined by the TEWG; signalling protocols (RSVP and CR-LDP) will also need to be modified. Proposal groups DiffServ classes into class types, for each of which you advertise unreserved B/W by preemption level. Semantics of Diffserv classes are configured in routers. Following questions were asked. Do we really need 8 preemption levels, and are 4 class types too many? How best to encode the TLVs, as they are getting large with 32 advertised bandwidths? Since OSPF is only involved in carrying this data, maybe most of this work belongs in TEWG (same comment applies to other OSPF TE drafts)?

2) "OSPF Extensions to Support Inter-Area Traffic Engineering" <draft-venkatachalam-ospf-traffic-00.txt>, presented by Senthil K. Venkatachalam. Extends traffic engineering across areas, using a separate Opaque-LSA that advertises metrics ala the Katz-Yeung draft, this time for inter-area destinations. Summarization is configurable: configure primary metric to give "shortest path", and then advertise the other parameters associated with that path. For additive metrics (e.g., TE metric), advertise minimum, for min-max (e,g., bandwidth) advertise max bottleneck, and for color advertise bit-wise "and". Another I-D extends TE across ASes using BGP. Questions: Is there any signalling support? (Not yet, perhaps need a framework document for TE across areas). Will you ever advertise multiple summary TE LSAs for single destination? (Yes, if want to do several different summarizations simultaneously).

3) "NSSA Update" by Pat Murphy. Currently on the -09 version. Pat again went over the rationale for the NSSA enhancements. Current document will be submitted as a Proposed standard after a working group last call, as Pat has promised not to make any more changes. Question as to whether the current document correctly limits the areas involved in the ASBR routing calculation.

4) "OSPF MIB update" <draft-ietf-ospf-mib-update-02.txt> presented by Spencer Giacalone. MIB updated for Opaque-LSAs, basic TE support, RFC 2328, and NSSA update. Security issues of cascading vulnerabilities addressed though comments in the MIB -- if not SNMPv3, certain items are read-only.

5) "OSPF Stub Router Advertisement" <http://www.employees.org/~azinin/draft-ietf-ospf-stub-adv-00.txt> presented by Liem Nguyen. By advertising transit links with highest cost (0xffff), makes router less attractive to transit traffic when a) in critical condition, b) when first introduced to network. Still can access router's local stub networks. Question as to whether it is worthwhile to worry about interoperability with the LSInfinity link cost last supported in RFC 1247. Will be merged with the similar proposal <draft-mcpherson-ospf-transient-00.txt>.

6) "Implementation of OSPFv3 in Zebra" presented by Yasuhiro Ohara [yasu@SFC.WIDE.AD.JP]. Free, open source (GPL2 copyright) written from scratch (www.zebra.org). 16,790 lines of C (three rewrites). Supports dynamic reconfiguration. Does not yet support areas or SNMP. Deployed in an operational network of 27 OSPFv3 routers, with a database of 145 LSAs (84 AS scoped, 61 area scoped). This is a native IPv6 network, except for a single tunnel.

7) "Network Engineering Extensions (NEXT) for OSPFv3" <draft-giacalone-te-optical-next-00.txt> by Spencer Giacalone. Adds traffic engineering information to OSPFv3, including similar support to the TE support and Optical routing support being proposed for OSPFv2, as well as delay calculations, additional metrics, and route calculations in future drafts. Question as to what products this protocol is intended for.

8) Pat Murphy discussed two other possible OSPF enhancements: (a) The ability to assign multiple areas to unnumbered point-to-point links. Pat suggests a mechanism using Opaque-LSAs <draft-ietf-ospf-mlinks-01.txt> (b) The ability to prevent flooding over certain links. Pat suggests defining a base flooding topology that will be advertised in Opaque-LSAs.

Minutes reported by John Moy (jmoy@sycamorenet.com)


None received.