The OSPF Working Group met in a single session at the Washington, D.C. IETF, on Wednesday December 10 from 1300-1500. Minutes of the meeting follow. (1) There was a status report on the three Working Group documents undergoing Working Group last call: o The OSPFv2 specification. This is scheduled to be submitted to the IESG for publication as a Full Standard, replacing RFC 2178. Changes include rate-limiting responses to less recent LSAs, and modification of the ASBR/forwarding address tiebreakers, as specified in . One more change to the flooding of MaxAge LSAs is necessary, and the I-D will be reissued. We are taking care to fix all of the possible flooding problems, since some people are starting to experiment with the removal of LSA refresh through setting DoNotAge. We will use the current standardization report, but need gross OSPF deployment estimates from vendors. o The OSPF for IPv6 specification . This has been updated to reflect changes in IPv6 and in the OSPFv2 base spec. Scheduled to be submitted to the IESG for publication as a Proposed Standard, we need information on any implementations (completed, ongoing, or planned). Ran asked whether we should publish the OSPF for IPv6 spec before IPv6 has settled on an addressing plan. Since OSPF for IPv6 just advertises arbitrary prefixes, this should be OK. o The Opaque-LSA specification . Scheduled to be submitted to the IESG for publication as a Proposed Standard. This document is important since future extensions to OSPFv2 will use the Opaque-LSA, since we have exhausted the OSPFv2 Options field. Uses of the Opaque-LSA have already been defined (for example, the ARA advertisement); however, there are not any implementations yet. (2) Ran Atkinson spoke about key management for OSPF . 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. (3) Jeffrey Zhang presented the latest draft of his 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. (4) Rob Coltun presented his latest ARA draft . 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. (5) Tony Przygienda talked about discovering OSPF neighbors through the Proxy PAR mechanism . 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. (6) Jeffrey Zhang gave an update on the QOSPF protocol , 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. (7) 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.