The OSPF Working Group met for a single session at the 44th IETF in Minneapolis, from 1545-1800 on 3/16/99. Minutes of the working group session follow, as recorded by John Moy. 1. OSPF Extensions for Traffic Engineering. There were two proposals in this area, which dealt with the encoding of traffic parameters in LSAs, in line with the similar parameters introduced into IS-IS in . Before the WG meeting, the two OSPF proposals ( by Derek Yeung of Cisco, and one that had been sent to the list by Dave Katz of Juniper) were merged, and Dave presented the resulting proposal. The encoding of traffic parameters was kept flexible, because traffic engineering is in its infancy and will probably evolve. Self-padding TLVs were used. Right now only transmit parameters are advertised, but receive parameters will be added in the future. It was agreed that there would be a separate "traffic engineering" LSA for each link, in order to keep the LSAs small. Dave's goal is to reach agreement on the encodings as soon as possible. It has been useful to advertise an IP address for each router for traffic engineering purposes; this will be done in the standard OSPF router-LSA. 2. Additional Traffic Engineering Extensions. Walt Wimer of FORE presented his draft . Additional traffic parameter encodings were proposed for link propagation delay and packet loss per diffserv codepoint. Curtis Villamizar said that how often these parameters are flooded should be specified. 3. Cheryl Sanchez of Avici proposed several other traffic parameters to be advertised within OSPF: the current fault protected bandwidth reservation (for fast reroute), current link utilization, and the probability of packet drops. It was mentioned that instead of bringing these proposals for new traffic parameters to all the concerned working groups, that maybe a new working group be formed to keep track of Traffic Engineering concerns. 4. Multipath Issues in Unicast and Multicast. Dave Thaler of Microsoft presented . While not particular to OSPF, this should be of general interest to OSPF developers. The goal of the draft is to fix broken multipath implementations, but not to try to enumerate all possible next hop selections. Three sample multipath forwarding algorithms are provided in the draft; their applicability depends on whether the implementation is keeping flow state. The draft applies to both unicast and multicast. PIM could use these algorithms to spread out load based on multicast group. MOSPF could do the same. 5. OSPF Optimized Multipath. Curtis Villamizer of UNNET gave an update on . Examples in the draft are now simulated, see http://engr.ans.net/ospf-omp/worked-example.html. Simulations are now being run on UUNET's real topology. OSPF-OMP did better than a simple LSP layout strategy, and converged faster than MPLS-OMP (although it required carefully configured link metrics). Curtis is interested in experimenting with more sophisticated LSP layout algorithms. OSPF-OMP parameters have been experimentally set; some of them (flooding and load adjustment timers) can cause instability if set inconsistently. Which, if any, parameters need to be set the same in all routers? If an implementation does not keep track of all equal-cost paths, OSPF-OMP will still work but not as optimally. If traffic parameters are not reported for some links those links are assumed to be completely unloaded. Curtis is looking for implementations. He believes that there are no implementations yet due to a combination of factors: a) the algorithms are hard, b) src/destination hash forwarding is not available in some hardware, and c) there are still questions about OSPF-OMP's stability. 6. The OSPF NSSA Option. Pat Murphy of the US Geological Survey gave a review of the major points of , including the configuration of the translating router(s), advertising of the default when summary-LSAs are inhibited, and the "P-bit paradox". The draft will now undergo minor editing and will then go to working group last call on the way to replacing RFC 1587. 7. OSPF ABR behavior. John Moy presented Alex Zinin's (AMT Group) document , which contains two proposals for optimizing inter-area traffic. The first, called "short-cut ABR", allows area border routers to examine all areas' summary-LSAs (instead of just area 0's). A rule on origination of summary-LSAs prevents bad convergence behavior (such as counting to infinity) in the inter-area routing. The second option, called "transit router", is based on behavior currently implemented in the cisco and IBM routers. In this option, a router acts as an area border router only if it has an active attachment to the backbone area. Acee Lindem wanted the definition of area border router changed accordingly, but John Moy thought that it was too late to make such a change to the base OSPF protocol. It was pointed out that aggregation still gets in the way of optimal inter-area routing. 8. OSPF Multiple Area Links. Pat Murphy ended the meeting with a few thoughts on , which among other things is capable of supporting multiple areas over an unnumbered point-to-point link.