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.