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 John Moy 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 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 Alex Zinin, Peter Psenak 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) Alex Zinin 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) Howard Berkowitz 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) Dan Joyal 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) Rohit Dube 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 P. Pillay-Esnault (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) S. Felix Wu 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 Zinin 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.