NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97
Chair(s):
John Moy <jmoy@casc.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Routing Area Advisor:
Joel Halpern <jhalpern@newbridge.com>
Mailing Lists:
General Discussion:ospf@gated.cornell.edu
To Subscribe: ospf-request@gated.cornell.edu
Archive: ftp://gated.cornell.edu/pub/lists/ospf
Description of Working Group:
The OSPF Working Group will develop and field-test an SPF-based Internal Gateway Protocol. The specification will be published and written in such a way so as to encourage multiple vendor implementations.
Goals and Milestones:
Jun 96 |
|
Complete OSPF for IPv6 specification and submit to IESG for consideration as a Proposed Standard. |
Jun 96 |
|
Document current usage, update OSPFv2 and submit to IESG for consideration as a Standard. |
Dec 96 |
|
Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. |
Dec 96 |
|
Submit Internet-Draft on ISPF extensions of IPv6 to IESG for consideration as a Proposed Standard. |
Jun 97 |
|
Update OSPF for IPv6 based on implementation experience, and submit to IESG for consideration as a Draft Standard. |
Done |
|
Gather operational experience with the OSPF protocol and submit the document as an Informational RFC. |
Done |
|
Develop multiple implementations, and test against each other. |
Done |
|
Obtain performance data for the protocol. |
Done |
|
Design the routing protocol, and write its specification. |
Done |
|
Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC. |
Jun 98 |
|
Submit OSPF for IPv6 to IESG for consideration as a Standard. |
Internet-Drafts:
· OSPF for IPv6
· The OSPF Opaque LSA Option
· OSPF Standardization Report
· The OSPF NSSA Option
· The OSPF Address Resolution Advertisement Option
· OSPFv2 Domain Of Interpretation (DOI) for ISAKMP
· SPF over ATM and Proxy PAR
· OSPF Version 2
Request For Comments:
RFC |
Status |
Title |
RFC1245 |
OSPF Protocol Analysis | |
RFC1246 |
Experience with the OSPF Protocol | |
RFC1586 |
Guidelines for Running OSPF Over Frame Relay Networks | |
RFC1587 |
PS |
The OSPF NSSA Option |
RFC1765 |
E |
OSPF Database Overflow |
RFC1793 |
PS |
Extending OSPF to Support Demand Circuits |
RFC1850 |
DS |
OSPF Version 2 Management Information Base |
RFC2096 |
PS |
IP Forwarding Table MIB |
RFC2178 |
DS |
OSPF Version 2 |
Minutes of the Open Shortest Path First IGP (OSPF) Working Group
I. Status report on the three Working Group documents undergoing Working Group last call:
· The OSPFv2 specification. This is scheduled to be submitted to the IESG for publication as a Full Standard, replacing RFC 2178. Changes include rate-limiting responses to less recent LSAs, and modification of the ASBR/forwarding address tiebreakers, as specified in <draft-ietf-ospf-vers2-01.txt>. One more change to the flooding of MaxAge LSAs is necessary, and the I-D will be reissued. We are taking care to fix all of the possible flooding problems, since some people are starting to experiment with the removal of LSA refresh through setting DoNotAge. We will use the current standardization report, but need gross OSPF deployment estimates from vendors.
· The OSPF for IPv6 specification <draft-ietf-ospf-ospfv6-05.txt>. This has been updated to reflect changes in IPv6 and in the OSPFv2 base spec. Scheduled to be submitted to the IESG for publication as a Proposed Standard, we need information on any implementations (completed, ongoing, or planned). Ran asked whether we should publish the OSPF for IPv6 spec before IPv6 has settled on an addressing plan. Since OSPF for IPv6 just advertises arbitrary prefixes, this should be OK.
· The Opaque-LSA specification <draft-ietf-ospf-opaque-02.txt>. Scheduled to be submitted to the IESG for publication as a Proposed Standard. This document is important since future extensions to OSPFv2 will use the Opaque-LSA, since we have exhausted the OSPFv2 Options field. Uses of the Opaque-LSA have already been defined (for example, the ARA advertisement); however, there are not any implementations yet.
II. Ran Atkinson spoke about key management for OSPF <draft-ietf-ospf- doi-00.txt>.
The main issue is that the current key exchanges in Oakley don't support multicast. There are some multicast key management schemes emerging, such as GKMP, MKMP, and a CBT-derived proposal. Oakley generates the session key dynamically, so even multiple unicast key exchanges won't work for OSPF, which requires that all OSPF routers attached to a common segment have the same session key. Need some way to distribute a precomputed key instead.
III. Jeffrey Zhang presented the latest draft of Dynamic Virtual Links proposal
<draft-zhang-ospf-dvl-01.txt>.
This is a continuation of work begun two years ago. Work solves two problems, namely a) virtual links are too hard to configure, and b) for fault tolerance, excess virtual links need to be configured which waste resources. Instead, routers figure out the minimum number of virtual links that are required for connectivity, and bring them up (and down) when needed. Discussion centered on how to decide when (and which) dynamic virtual lines to remove when they were no longer necessary. Original draft just proposed using random timers; current draft proposes using a MOSPF-like Dijkstra tie-breaker. John Moy said that a minimum spanning tree calculation which prefers normal links might find more excess links. Jeff Pickering pointed out that if excess virtual links are not an issue, you can simply establish virtual links between every pair of area border routers.
IV. Rob Coltun presented his latest ARA draft <draft-ietf-ospf-ara- 01.txt>.
ARA advertisements are used to distribute ATM address mappings, for use in the establishment of ATM shortcuts. Shortcuts are used by data traffic, but OSPF packets are transmitted over the normal paths. When asked to contrast ARAs with MPOA, Rob said that ARAs are more scalable, and are router-to-router instead of host-to-host. For example, ARA could be used for best effort shortcuts, and MPOA for QoS-specific shortcuts. The ARA draft now has a "logical network" concept, which can be thought of as providing closed user groups. For example, an OSPF routing domain encompassing multiple ATM clouds can treat each cloud as a separate logical network for ARA shortcuts. Inter-area ARA advertisements for networks are used only when addresses are not being aggregated.
V. Tony Przygienda talked about discovering OSPF neighbors through the Proxy PAR mechanism
<draft-ietf-ospf-atm-00.txt>.
This uses the PNNI protocol to advertise the identity of OSPF routers attached to an ATM cloud. OSPF routers perform a registration protocol with the ATM switch, and are informed of other OSPF routers belonging to the same area. Protocol uses soft state, and so registration must be continually refreshed. After discovering the neighbor, all regular OSPF mechanisms apply, including the sending and received of OSPF Hellos. Proxy PAR is mainly envisioned to be useful when SVCs are used over ATM, and the OSPF routers are organized into an NBMA subnet.
VI. Jeffrey Zhang gave an update on the QOSPF protocol <draft-zhang- qos-ospf-01.txt>
This protocol was last presented at the Munich IETF in the QOSR Working Group. In answer to questions, Jeffrey explained that even without pinning, the Router Reservation Advertisement (RRA) LSA would be needed anyway. To solve the scaling problems with RRAs, explicit routing can be used in QOSPF. Jeffrey said that using two metrics doesn't adversely affect Dijkstra performance, and that QOSPF uses the same routing calculation whether or not explicit routing is used. QOSPF has been implemented within the Bay router, but not the explicit routing option.
VII. Pat Murphy gave an update on the NSSA area specification.
The current draft is in error, and will be amended so that area border routers advertise their defaults in Type-7 (not Type 3) LSAs.
None Received