NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
John Moy <jmoy@casc.com>
Routing Area Director(s):
Rob Coltun <rcoltun@fore.com>
Routing Area Advisor:
Rob Coltun <rcoltun@fore.com>
Mailing Lists:
General Discussion:ospf@discuss.microsoft.com
To Subscribe: ospf-request@discuss.microsoft.com
Archive: http://discuss.microsoft.com/archives/ospf.html
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:
Request For Comments:
RFC |
Status |
Title |
RFC1246 |
Experience with the OSPF Protocol | |
RFC1245 |
OSPF Protocol Analysis | |
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 |
RFC2328 |
S |
OSPF Version 2 |
RFC2329 |
OSPF Standardization Report | |
RFC2370 |
PS |
The OSPF Opaque LSA Option |
The OSPF Working Group met at the 43rd IETF in Orlando, FL, for a single session on Tuesday December 8 from 1300-1515. The following minutes of the meeting were recorded by John Moy.
1) Sanjay Kamat gave a report on the "QoS Routing Mechanisms and OSPF
Extensions" work done by Apostolopoulos, Guerin, Kamat, Orda, Przygienda, and Williams. The specification will be published as an Experimental RFC, and an implementation in GATED will soon be available. (Note: Spec has recently been published as the Internet Draft <draft-guerin-qos-routing-ospf-04.txt>). It is a modification to OSPF for constraint-based routing, using a single bandwidth constraint. It allows a signalling protocol (RSVP in the GATED implementation) to query the routing protocol for a route to a destination having a minimum amount of available bandwidth; what is returned is either a next hop or an explicit route which satisfies the constraint and minimizes hop count.
The implementation is based on GATED version 4 (the so-called new OSPF). It is for a single area only, and assumes all OSPF routers are running the QoS modifications. Explicit routes have not been implemented. A QoS route table is built, with a generic API; RSVP is currently the entity that is querying the table. Questions, comments, and bug reports concerning the implementation can be sent to ospf-qos@watson.ibm.com.
Experiments have been performed relating the rate of path pre-computation and LSA generation to the blocking rate. A simulation was used, and the results were then compared to a small operational network. The conclusion is that reducing the rate of computation and LSA generation is worthwhile, leading to considerable savings in CPU and control traffic while increasing the blocking rate only slightly.
Questions brought out several other points:
- No distinction is made between controlled load and guaranteed service. Both are translated into a bandwidth requirement.
- Operation in a multi-area environment has yet to be specified. Sanjay thought that more experiments with the single area case are required before consideration of the multi-area case.
- Adding additional metrics, like delay, in general makes the problem NP-complete. However, additional metrics that are used as filters (such as the minimum bandwidth requirement) can be introduced without increasing complexity.
2) Curtis Villamizar presented his work on OSPF Optimized
Multipath (OSPF-OMP <draft-ietf-ospf-omp-01.txt>). The idea is to more intelligently assign packets to one of several equal-cost paths, so as to keep individual link utilizations at a reasonable level. In standard equal-cost multipath, a hash function of the packet's source and destination separates traffic into equal-sized buckets. In OMP, load information advertised in LSAs changes the hash boundaries, assigning more traffic to lightly loaded paths. There are no routing loops, because traffic always follows one of the least cost paths. However, potentially you could get oscillations between the equal-cost paths. While stability of OMP has not be proven, Curtis' simulations have shown convergence to a steady state, generally within 20 minutes.
The best path criteria has been relaxed to also consider "almost equal-cost paths". While OMP balances load based on the worst link in the path, simulation has shown that partial path adjustment will need to be performed in some cases. Link costs must in any case be carefully configured so that there are equal-cost (or almost equal-cost) paths available to work with; link failures generally mess up these carefully configured costs.
Hash functions such as CRC-16 distribute load nicely when there are a lot of source-destination pairs (such as in a backbone ISP), but may not work as well in an enterprise environment.
3) John Moy talked about "MOSPF Prunes" <draft-ietf-mospf-prunes-00.txt>.
This introduces DVMRP-like pruning into MOSPF, limiting the extent of multicast datagrams in an hierarchical MOSPF environment. Prunes are implemented as link-local Opaque-LSAs. Dave Thaler mentioned that support for arbitrary source prefixes are necessary for interoperability with PIM. Source-specific grafts would also be useful, but source-specific prunes gives you as good a behavior as you currently get with DVMRP.
4) John Moy described the bug fixes that have been added to the most recent version of the MOSPF specification <draft-ietf-mospf-mospf-01.txt>). These are described in Sections D.1.5 and D.1.6 of the Internet Draft.
OSPF Optimized Multipath
QoS Extensions to OSPF - Experiment work with GateD