The OSPF Working Group met at the 48th IETF on Monday, July 31 from 1530-1730. The meeting began with mention of the last calls that can be expected in the near future: the OSPFv3 MIB to proposed, the revised OSPFv2 MIB (standards level to be negotiated with NM ADs) and the NSSA Update document (Proposed). The following presentations were then given. 1. Francois Le Faucheur presented "extensions to OSPF for Diff-Serv TE" . This makes the link bandwidth allocation to DiffServ classes visible to routing, so that, for example, paths for EF (expedited forwarding) traffic can be restricted to those links having a small percentage of existing EF traffic. Requirements for Diffserv-aware MPLS TE are being defined by the TEWG; signalling protocols (RSVP and CR-LDP) will also need to be modified. Proposal groups DiffServ classes into class types, for each of which you advertise unreserved B/W by preemption level. Semantics of Diffserv classes are configured in routers. Following questions were asked. Do we really need 8 preemption levels, and are 4 class types too many? How best to encode the TLVs, as they are getting large with 32 advertised bandwidths? Since OSPF is only involved in carrying this data, maybe most of this work belongs in TEWG (same comment applies to other OSPF TE drafts)? 2. "OSPF Extensions to Support Inter-Area Traffic Engineering" , presented by Senthil K. Venkatachalam. Extends traffic engineering across areas, using a separate Opaque-LSA that advertises metrics ala the Katz-Yeung draft, this time for inter-area destinations. Summarization is configurable: configure primary metric to give "shortest path", and then advertise the other parameters associated with that path. For additive metrics (e.g., TE metric), advertise minimum, for min-max (e,g., bandwidth) advertise max bottleneck, and for color advertise bit-wise "and". Another I-D extends TE across ASes using BGP. Questions: Is there any signalling support? (Not yet, perhaps need a framework document for TE across areas). Will you ever advertise multiple summary TE LSAs for single destination? (Yes, if want to do several different summarizations simultaneously). 3. "NSSA Update" by Pat Murphy. Currently on the -09 version. Pat again went over the rationale for the NSSA enhancements. Current document will be submitted as a Proposed standard after a working group last call, as Pat has promised not to make any more changes. Question as to whether the current document correctly limits the areas involved in the ASBR routing calculation. 4. "OSPF MIB update" presented by Spencer Giacalone. MIB updated for Opaque-LSAs, basic TE support, RFC 2328, and NSSA update. Security issues of cascading vulnerabilities addressed though comments in the MIB -- if not SNMPv3, certain items are read-only. 5. "OSPF Stub Router Advertisement" presented by Liem Nguyen. By advertising transit links with highest cost (0xffff), makes router less attractive to transit traffic when a) in critical condition, b) when first introduced to network. Still can access router's local stub networks. Question as to whether it is worthwhile to worry about interoperability with the LSInfinity link cost last supported in RFC 1247. Will be merged with the similar proposal . 6. "Implementation of OSPFv3 in Zebra" presented by Yasuhiro Ohara [yasu@SFC.WIDE.AD.JP]. Free, open source (GPL2 copyright) written from scratch (www.zebra.org). 16,790 lines of C (three rewrites). Supports dynamic reconfiguration. Does not yet support areas or SNMP. Deployed in an operational network of 27 OSPFv3 routers, with a database of 145 LSAs (84 AS scoped, 61 area scoped). This is a native IPv6 network, except for a single tunnel. 7. "Network Engineering Extensions (NEXT) for OSPFv3" by Spencer Giacalone. Adds traffic engineering information to OSPFv3, including similar support to the TE support and Optical routing support being proposed for OSPFv2, as well as delay calculations, additional metrics, and route calculations in future drafts. Question as to what products this protocol is intended for. 8. Pat Murphy discussed two other possible OSPF enhancements: (a) The ability to assign multiple areas to unnumbered point-to-point links. Pat suggests a mechanism using Opaque-LSAs (b) The ability to prevent flooding over certain links. Pat suggests defining a base flooding topology that will be advertised in Opaque-LSAs. Minutes reported by John Moy (jmoy@sycamorenet.com)