2.5.10 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97

Chair(s):

John Moy <jmoy@casc.com>

Routing Area Director(s):

Joel Halpern <jhalpern@newbridge.com>

Routing Area Advisor:

Joel Halpern <jhalpern@newbridge.com>

Mailing Lists:

General Discussion:ospf@gated.cornell.edu
To Subscribe: ospf-request@gated.cornell.edu
Archive: ftp://gated.cornell.edu/pub/lists/ospf

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

 

RFC1245

 

OSPF Protocol Analysis

RFC1246

 

Experience with the OSPF Protocol

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

RFC2178

DS

OSPF Version 2

Current Meeting Report

Minutes of the Open Shortest Path First IGP (OSPF) Working Group

I. Status report on the three Working Group documents undergoing Working Group last call:

II. Ran Atkinson spoke about key management for OSPF <draft-ietf-ospf- doi-00.txt>.

The main issue is that the current key exchanges in Oakley don't support multicast. There are some multicast key management schemes emerging, such as GKMP, MKMP, and a CBT-derived proposal. Oakley generates the session key dynamically, so even multiple unicast key exchanges won't work for OSPF, which requires that all OSPF routers attached to a common segment have the same session key. Need some way to distribute a precomputed key instead.

III. Jeffrey Zhang presented the latest draft of Dynamic Virtual Links proposal

This is a continuation of work begun two years ago. Work solves two problems, namely a) virtual links are too hard to configure, and b) for fault tolerance, excess virtual links need to be configured which waste resources. Instead, routers figure out the minimum number of virtual links that are required for connectivity, and bring them up (and down) when needed. Discussion centered on how to decide when (and which) dynamic virtual lines to remove when they were no longer necessary. Original draft just proposed using random timers; current draft proposes using a MOSPF-like Dijkstra tie-breaker. John Moy said that a minimum spanning tree calculation which prefers normal links might find more excess links. Jeff Pickering pointed out that if excess virtual links are not an issue, you can simply establish virtual links between every pair of area border routers.

IV. Rob Coltun presented his latest ARA draft <draft-ietf-ospf-ara- 01.txt>.

ARA advertisements are used to distribute ATM address mappings, for use in the establishment of ATM shortcuts. Shortcuts are used by data traffic, but OSPF packets are transmitted over the normal paths. When asked to contrast ARAs with MPOA, Rob said that ARAs are more scalable, and are router-to-router instead of host-to-host. For example, ARA could be used for best effort shortcuts, and MPOA for QoS-specific shortcuts. The ARA draft now has a "logical network" concept, which can be thought of as providing closed user groups. For example, an OSPF routing domain encompassing multiple ATM clouds can treat each cloud as a separate logical network for ARA shortcuts. Inter-area ARA advertisements for networks are used only when addresses are not being aggregated.

V. Tony Przygienda talked about discovering OSPF neighbors through the Proxy PAR mechanism
<draft-ietf-ospf-atm-00.txt>.

This uses the PNNI protocol to advertise the identity of OSPF routers attached to an ATM cloud. OSPF routers perform a registration protocol with the ATM switch, and are informed of other OSPF routers belonging to the same area. Protocol uses soft state, and so registration must be continually refreshed. After discovering the neighbor, all regular OSPF mechanisms apply, including the sending and received of OSPF Hellos. Proxy PAR is mainly envisioned to be useful when SVCs are used over ATM, and the OSPF routers are organized into an NBMA subnet.

VI. Jeffrey Zhang gave an update on the QOSPF protocol <draft-zhang- qos-ospf-01.txt>

This protocol was last presented at the Munich IETF in the QOSR Working Group. In answer to questions, Jeffrey explained that even without pinning, the Router Reservation Advertisement (RRA) LSA would be needed anyway. To solve the scaling problems with RRAs, explicit routing can be used in QOSPF. Jeffrey said that using two metrics doesn't adversely affect Dijkstra performance, and that QOSPF uses the same routing calculation whether or not explicit routing is used. QOSPF has been implemented within the Bay router, but not the explicit routing option.

VII. Pat Murphy gave an update on the NSSA area specification.

The current draft is in error, and will be amended so that area border routers advertise their defaults in Type-7 (not Type 3) LSAs.

Slides

None Received

Attendees List

go to list

Previous PageNext Page