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 (<draft-
        ietf-ospf-version2-08.txt>) can be submitted for publication as a
        Full Standard, replacing RFC 1583.  John Moy summarized the required
        standardization report (<draft-ietf-ospf-stdreport-00.txt>). 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 (<draft-ietf-ospf-ospfv6-03.txt>)
        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 (<draft-ietf-ospf-opaque-00.txt>) 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" (<draft-guerin-qos-routing-ospf-00.txt>). 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.