CURRENT MEETING REPORT Reported by John Moy, Cascade Communications Corporation Minutes of the Open Shortest Path First IGP Working Group (OSPF) John Moy summarized the status of the various OSPF-related protocol documents, which is reflected in the following table. RFC # Title Standards status ____________________________________________________ 1850 OSPF V2 MIB Draft 1793 Demand circuit extensions Proposed 1765 Database Overflow Experimental 1745 BGP/OSPF interaction Proposed 1587 NSSA areas Proposed 1584 MOSPF Proposed 1583 OSPF V2 specification Draft We hope to submit the current OSPF V2 base spec (, which will replace RFC 1583) at the Montreal IETF for consideration for Full Standard Status. To that end, John will be sending implementation and deployment questionnaires to the OSPF and GATED mailing lists shortly, with the hope of quantifying current OSPF usage in the Internet. Rob Coltun presented his Opaque-LSA I-D. The Opaque-LSA is intended to carry information that is normally outside the scope of the OSPF protocol itself. Examples include BGP attributes (taking the place of the AS external attributes LSA), addressing information for other protocol stacks, and QoS-related parameters. It is also proposed that Opaque-LSAs have scopes, so that their flooding can be restricted to a single subnet, a single area, or a single AS. Opaque-LSAs would be optional for IPv4, but mandatory for IPv6 (where Rob proposed they would carry next hop information for AS external LSAs). Dennis Ferguson pointed out that the single-subnet-scoped Opaque- LSAs did not need to carry an address/mask pair, since this can be determined by context. It was pointed out that the address/mask could be useful if one wanted to flood certain LSAs subnet-wide or across a defined set of subnets--however, no one could think of an application so the address/mask was dropped. Dennis also pointed out that the fact that Opaque-LSAs would be optional in IPv4 would limit their usefulness. The same problem existed with the AS-external attributes LSA. Namely, since you were never sure that you had flooding connectivity for the AS-external attributes LSA, you were never sure that you were working with up-to- date information. Jeffrey Zhang presented his Dynamic Virtual links IDs. The point of this document is to be able to dynamically establish virtual links, instead of depending on the network administrators to configure them. Several comments questioned the necessity for the ID's election algorithm, and whether the document's method for tearing down unneeded dynamic virtual links could lead to thrashing. One or two alternate mechanisms were suggested. More discussion will occur on the OSPF mailing list. Rob Coltun presented his latest "OSPF for IPv6" draft. The draft supports instance Internet-Drafts (so you can more easily support multiple OSPF domains overlapping on one or more subnets), Opaque- LSAs, and increases the size of the Link State ID, Router ID and Area ID to 128 bits (i.e., equal to the IPv6 address size). The latter provoked a lot of discussion. Dennis wanted to keep all three at their current size of 32 bits, mainly to control the size of OSPF protocol packets. Rob gave the rationale for growing them to 128 bits: Router Internet-Draft and Area Internet-Draft are often assigned as IP addresses, and the Link State ID in OSPF LSAs often includes addressing semantics (e.g., in AS- external-LSAs). The pros and cons of leaving each item at 32 bits were then discussed separately: o Area ID Although at least one vendor had customers that assigned these as IP addresses, this did not seem to be the norm, and so was not regarded as a major issue. o Router ID All vendors do assign this as an IP address, so leaving this at 32 bits seemed to be an operational issue. Some people suggested that since there are going to be IPv4 addresses for the forseeable future, we just continue to assign Router ID as Ipv4 addresses. Others advocated randomly generated Internet-Drafts with an algorithm for collision detection. Another suggestion was for 64-bit Router ID, with the lower 48-bits a unique IEEE MAC address. Other people said that an assignment strategy was outside the scope of the protocol itself, and that it was enough to leave uniqueness of Router IDs to the system administrators. Lastly, there was a volunteer to set up a router ID registry for $50 a Router ID. o Link State ID Some people argued that taking the addressing semantics out of Link State Internet-Drafts was too large a protocol change. And it would make OSPF debugging (packet traces, etc) harder. On the other side, an argument was made that keeping the Link State ID at 32-bits would mean less implementation changes, and would make it easier for OSPF to carry multi-protocol information. After the discussion, the general sense of the meeting was to try to keep the size of the Link State ID, Router ID and Area ID at 32- bits. Rob and Dennis signed up to update the Internet-Draft. The goal is to have a protocol document that can be submitted for Proposed Status by the next (Los Angeles) IETF.