Editor's note: These minutes have not been edited. The OSPF Working Group met on Wednesday, December 11th from 1300-2500 at the San Jose IETF. Minutes of the meeting follow: (1) We discussed the issues remaining before the OSPFv2 spec () can be submitted for publication as a Full Standard, replacing RFC 1583. John Moy summarized the required standardization report (). One incompatible change had been made, resulting in the new RFC1583Compatibility flag, which has to be set manually router-by- router through SNMP. Two new problems were then described, both of which require modifications to the reception of Database Description packets in OSPF. Both modifications are backward-compatible. The first problem, reported by Man-Kit Yeung of cisco, concerns retransmissions of the initial Database Description packets (those with the Init bit set). These can be continual due to, for example, high delay links, in which case the two neighbors will never start exchanging databases. The solution is to process these retransmissions just as you process duplicate Database Description packets in other states. The second problem, reported by Dan Senie of Proteon, concerns MTU mismatches between OSPF neighbors. This can cause flooding between the two neighbors to fail, with large Link State Updates being continually retransmitted. To fix this, we will report interface MTU in Database Description packets. A router will discard received Database Description packet which advertise an MTU that is larger than the router can receive. In this way, adjacencies will not form between routers having MTU mismatches. Tony Li expressed a desire for a more general purpose mechanism. There was also a question whether the same thing will have to be done for OSPF for IPv6 (we think so). (2) The current OSPF for IPv6 draft () was modified to prevent IPv6 link-local addresses from appearing in all LSAs except the Link-LSA, where they are used in the next hop calculation. The draft will not be submitted to the IETF standards track until implementation experience is gained. (3) Rob Coltun's Opaque-LSA draft () was reviewed. We intend to submit this for Proposed Standard, as a general way to add future extensions to OSPFv2. Jeffrey Zhang asked about adding a no-flooding option to the Opaque-LSA flooding scope. John Moy responded that standardization of no-flooding was unnecessary, as this could be handled equally well via private agreements. The Opaque-LSA also has a range of reserved types, which we expect will be assigned by IANA. (4) Doug Williams presented IBM's "QoS Routing Mechanisms and OSPF Extensions" (). This proposal advertises each link's available bandwidth, and optimizes based on hop count. Roch Guerin said hop count was used instead of the OSPF metric because it is too hard to meaningfully combine additive metrics. A good deal of the draft discusses how to efficiently precalculate paths with sufficient available bandwidth. A Bellman- Ford method and a method using Dijkstra's algorithm are both given; the Bellman-Ford is preferred because it doesn't require bandwidth quantization (which loses information). Several people mentioned that available bandwidth could be advertised in a backward- compatible fashion be using OSPF's TOS-encodings. (5) Patrick Murphy of the U.S. Geological Survey is working on an update to OSPF NSSA areas (RFC1587). Import of inter-area routes into NSSA areas is being made optional in some cases, and the preference rules for the external route calculation are being updated to match the latest OSPFv2 spec. Dennis Ferguson wondered whether the resulting preferences were metastable. Upon further examination, we think that they are OK, but this should be checked by the NSSA authors. Pat also described the network where he wants to use NSSA areas: an inter-agency network with many OSPF areas, and a lot of redistribution of data between OSPF and other routing protocols such as IGRP, RIP and IS-IS. (6) Mark Pullen and Lava Lavu presented an ongoing effort at George Mason University to simulate QOSPF. The simulation uses OpNet. They have simulated IGMP, RSVP, OSPF, and MOSPF, and are making their simulation code publicly available. They only have preliminary results, but future results will be available on http://bacon.gmu.edu/qosip. They are also looking for people to help validate their results.