2.5.9 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99

Chair(s):

John Moy <john.moy@sycamorenet.com>

Routing Area Director(s):

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

Routing Area Advisor:

Rob Coltun <rcoltun@siara.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 at the 46th IETF on Monday, 11/8, from 1300-1500.
The following are minutes of the meeting, as recorded by John Moy.

1. Working Group report, document status

Aside from the documents presented during the meeting, the Working Group documents that are currently under revision include the following. The OSPF for IPv6 specification is in the RFC editor's queue, ready to be published as a Proposed Standard. The updated MOSPF spec is due to be submitted for republication at Draft Standard, as soon as current deployment/interoperability status is documented. The NSSA spec is still being reworked (draft-ietf-ospf-nssa-update-08.txt), with the intent to republish it in-grade, replacing RFC 1587. The OSPFv2 MIB needs updating and advancement to Standard, to match the OSPFv2 spec. The Traffic Engineering Extensions to OSPF <draft-katz-yeung-ospf-traffic-01.txt> has two small issues to work out: how to keep the link metric encodings in sync with the IS-IS Traffic Engineering extensions, and how to assign new link metrics (such as an IfIndex metric for unnumbered links). Curtis Villamizar has changed jobs, so the URLs for OSPF Optimized Multipath (OSPF-OMP) no longer work, but Curtis intends to reorganize draft-ietf-ospf-omp-02 and publish it as an Experimental protocol.

2. Alternative OSPF ABR Implementations

This document describes the inter-area routing implementations of two vendors, cisco and IBM, which differ from standard OSPF inter-area routing. Both try to solve the problem in standard OSPF where area border routers not attached to Area 0.0.0.0 cannot forward packets to remote areas. The two vendors' solutions are different. There was a comment on the cisco implementation, which prevents some legal virtual link configurations from working (those where there is no physical Area 0.0.0.0). There was some question whether such configurations actually occur in practice. A request was made to remove words like "recommended" from the document, since it is simply documenting two current vendor implementations.

3. OSPF Shortcut ABR, Enhanced OSPF ABR Behavior (15 minutes)

These proposed extensions solve the problem with ABRs not attached to Area 0.0.0.0, and also optimize inter-area routing without the need for virtual links. Alex described them as an extension to the cisco and IBM behaviors presented earlier. Description of counting behavior that can occur when falling back to longer route has been added to document; this behavior can also occur in standard OSPF. There was a question of how CPU-intensive the short-cut behavior was. There was some confusion over what was required behavior in the OSPFv2 spec, caused by its lack of "musts" etc., particularly in the area of installing discard routes. Shortcut ABR has been implemented in the zebra routing daemon, which can be configured to do inter-area routing as a) standard, b) cisco, c) ibm or d) shortcut.

4. Techniques in OSPF-based Network (10 minutes)

This document tries to fill in gaps between the OSPF specifications and real deployments. For example, the OSPF spec uses the term Autonomous System in a way that is counter to current practice. Howard solicits input for other information that would be useful to people deploying OSPF.

5. Management Information Base for OSPFv3 (10 minutes)

This MIB is required since the companion protocol spec, OSPF for IPv6, is entering the standards track. Indexes in the lsdb table have been reordered since Link State IDs in OSPF for IPv6 no longer have any semantic meaning; all LSAs originated by a given router will now be dumped consecutively. Q: How to configure the interface addresses advertised by OSPF. A: Through some other MIB.

6. Redundant LSA reduction in OSPF (10 minutes)

This proposal attempts to reduce flooding in those situations where neighbors are highly interconnected, by omitting some neighbors from the flooding on a per-LSA basis. It is derived from the IS-IS Mesh Group proposal. Comments included the following: a) the resulting flooding is not reliable unless you use a Designed Router, in which case you just end up with NBMA flooding from the base OSPF spec b) you could use "mesh flooding" for only certain LSA types and c) maybe the LSA database could give you some indication as to which neighbors could be safely skipped in the flooding procedure. There was some concern that the last comment could give rise to a circular dependency between the database contents and its distribution via flooding, which could prevent database updating in certain situations.

7. OSPF Refresh and flooding reduction in stable topologies

(Document published after the meeting). This document proposes to reduce flooding through the use of MaxAge LSAs, which were defined originally in RFC 1793 (Demand Circuit extensions for OSPF). Comments included a) since the original router can now refresh whenever it chooses, you can now make the LSA refresh rate configurable on a per-router, per-LSA type basis and b) if you set the DoNotAge bit in the originating router's database, you don't mess up the database checksum.

8. Vulnerability analysis and intrusion detection for OSPF (25 minutes)

This is DARPA-funded work, to try to produce an Intrusion Detection system for OSPF. It detects and in some cases thwarts attacks on an OSPF routing domain. The objective of an attacker is to change routing so that data packets go through a compromised router. The authors have concentrated on attacks to OSPF's database distribution, and have identified and named a number of possible attacks, some taking advantage of implementation software bugs (e.g., the MaxSeqno attack) and other attacking the OSPF protocol design itself (the MaxAge difference attack). Intrusion detection is performed via a finite-state machine, or through a statistical module; code for both will be made available. They are also trying to detect intrusion by monitoring OSPF MIB variables. Future work includes a) a simulation testbed to generate data to compare with operation networks b) how to test intrusion responses so that they themselves won't harm the network. Felix will post papers describing the intrusion detection system onto the ospf mailing list.

9. Multi-level OSPF (MLOSPF) (15 minutes)

Alex presented unpublished work on the requirements and beginnings of an architecture for a multi-level (more than 2) hierarchy for OSPF. It would be backward-compatible with current OSPF. Areas can be grouped together into higher level areas. Inter-area routing would be link-state based instead of Distance Vector. Policy and aggregation would be possible at every area border, similar to the BGP model. More integration with BGP is proposed. This work is just beginning, and Alex solicits participation in MLOSPF protocol development. The mailing list for MLOSPF is mlospf@agtel.net, and its web page is http://babylon.agtel.net/~zinin/IETF/mlospf/mlospf.html.

Slides

Management Information Base for OSPFv3
Vulnerability Analysis and Intrusion Detection