CURRENT_MEETING_REPORT_ Reported by John Moy/Cascade Communications Minutes of the Open Shortest Path First IGP Working Group (OSPF) The OSPF Working Group met on Wednesday, December 7th at the San Jose IETF. OSPF Extensions for IPv6 Fred Baker led a discussion of the Internet-Draft ``OSPF Extensions for IPv6'' (draft-ietf-ospf-ipv6-ext-00.txt). Fred characterized the support as follows: o Integrated routing of IPv4 and IPv6. o Certain OSPF areas are labeled as ``IPv6-capable.'' All routers in these areas must be capable of IPv6 routing, although not all networks within need be assigned IPv6 addresses. On those networks with IPv6 addresses, OSPF will run over IPv6. There is no gradual conversion of an area to being ``IPv6-capable''; it must instead be done on a flag day. o There are new LSA types which are the IPv6 equivalents of the present OSPF LSAs. The IPv6 LS type is obtained by adding 16 to the IPv4 LSA type. For example, the IPv6 router-LSA is LSA type 17 (16+1). o In the IPv6 LSAs (and in the IPv6-encapsulated OSPF packet format), the Router ID, Link State ID, Advertising Router and Area ID have been increased from 4 to 16 bytes. The mask field remains at 4 bytes, but now indicates the number of significant bits. Fred said that the requirement for contiguous masks has now been blessed by the IESG. Besides these changes, the only IPv6 LSA that is significantly different from its IPv4 equivalent is the router-LSA. In particular, since router-LSAs are now getting large, a way of fragmenting IPv6 router-LSAs is defined. o For IPv6, there is a new Opaque-LSA type. For example, if IPX addresses are embedded in IPv6 the Opaque-LSA can be used to carry SAP information. In the discussion that followed, a number of points were brought up: There will not be an IPv6 equivalent of the type-8 (external-attributes) LSA. It will be subsumed by the opaque-LSA. In support of this, we must document that the Link State ID of the opaque-LSA (when carrying BGP/IDRP path info) must equal the tag in the IPv6 AS-external-LSAs. For this reason, maybe the tag field should be extended to 16 bytes? Some people saw problems with requiring a flag day to convert areas to being IPv6-capable. The DECNet Phase IV to Phase V migration was given as an example. It was noted that there are mechanisms for piece-wise converting areas to new functionality (like is being done for the OSPF demand circuit support), but that they are somewhat complicated. There was a good deal of discussion of Integrated routing. Many people seemed to think that integrated routing is OK in this case, since IPv4 and IPv6 are so similar. It was noted that the problem with Integrated IS-IS was that the OSI and IP area boundaries typically did not match. Fred also said that integrated routing of IPv4 and IPv6 is being mandated by the IPng directorate. Other people said that assuming IPv6 and IPv4 would be so similar might be a mistake. It was also noted that the SIN approach makes transition easier, again referencing Phase IV to Phase V conversion. IPv6 addresses that cannot be translated to IPv4 addresses must be discarded at IPv4-only area boundaries. IPv6-capable routers need both an IPv6 Router ID and an IPv4 Router ID. It was noted that these could both be provided by a single translatable IPv6 address belonging to one of the router's interfaces. OSPF MD5 Authentication o Ran Atkinson described the current OSPF MD5 authentication Internet-Draft (draft-ietf-ospf-md5-02.txt), and then led a lively discussion of its contents. The following issues were brought out: o Instead of ``lifetime,'' it would be clearer to talk about a key's ``start time'' and ``end time.'' End time is necessary so that keys can be taken out-of-service; otherwise, compromised keys will continue to be accepted. o The document mandates multiple keys be supported so that a smooth changeover from one key to another can be accomplished. o The document needs to be clearer about the use of new keys. There are two times that are important here: a) When a new key will be accepted in received packets and b) when the new key will be used for transmitted packets. There must be some overlap for smooth transition. It was noted that the RouterDeadInterval gives a grace period; some people did not want to have to depend upon this however. Also, perhaps the new key's start time should be related to the old key's end time. o There were questions on whether routers now need a time-of-day clock, or whether relative time suffices. If time-of-day clock is necessary, there was a question on how synchronized routers' clocks must be. o There was a question of how routers should operate on restart. Should they have to get keys anew, or should the keys persist across restarts? Changes to the OSPF MIB Fred Baker described the changes that have occurred to the OSPF MIB since RFC 1253. More additions have to be made for the Demand Circuit and Database Overflow support. Also, the MIB does not reflect IPv6 in any way. Since we want to republish the MIB soon, any changes should be sent to Fred as soon as possible. Extending OSPF to Support Demand Circuits John Moy summarized the current ``Extending OSPF to support demand circuits'' Internet-Draft (draft-ietf-ospf-demand-01.txt), and explained the changes made to the previous draft. The following issues we brought up during the discussion: o Some people wanted a more explicit description of how call collisions are handled/avoided. More words on how to randomize timers is needed. o In order to deal with call collisions, and also to avoid unnecessary calling charges, perhaps an exponential backoff procedure for failed call attempts is a good idea. o Other people expressed concern that OSPF should not specify handling of things (like call collision) that are better off solved in a generic way by the data-link layer. o The requirements of both ends of a circuit be capable of dialing was a problem for some people. John noted that the real requirement was only that the connection initiator be able to dial. o Charles Slater requested that routing changes not be sent over a link until the link was established for data traffic. John said that that was difficult to do in some situations, and impossible in others, while still having the routing work completely. Charles indicated that he was willing to live with some level of routing failures in order to optimize dial-up charges. John indicated that the current way of isolating routing changes, namely configuring area boundaries, should be better described in the specification. Area boundaries function like routing filters, which is what some dial-up routers do today. o It was mentioned that it is sometimes impossible to determine whether a busy signal truly means busy. It may mean instead that part of the network is broken. o It was noted that often to get the most effective use of dial-up lines, you need application-dependent routing, which is not supported by the draft. Dawn Li then presented testing results of 3Com's implementation of the demand circuit support. 3Com and ACC have both implemented the previous draft of the demand circuit support. Gerry Meyer then contrasted RIP support for demand circuits with OSPF's. RIP specifies how to handle oversubscription, while OSPF only provides a suggestion. John said that the suggestion could be upgraded to a required behavior, if experience/simulation shows that it is a good way to handle oversubscription. Gerry recommended that this be done as soon as possible. RIP also does not route through 3rd parties, always establishing demand circuits directly to the destination. OSPF Database Overflow John Moy then quickly summarized the ``OSPF Database Overflow'' Internet-Draft (draft-ietf-ospf-overflow-00.txt), which is the result of previous working group discussions. Extending OSPF to Better Support RSVP The meeting ended with Tom Pusateri asking for help in extending OSPF to better support RSVP. Interested parties should contact Tom.