Last Modified: 2005-09-27
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 | Design the routing protocol, and write its specification. | |
Done | Obtain performance data for the protocol. | |
Done | Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC. | |
Done | Submit OSPF for IPv6 to IESG for consideration as a Standard. | |
Done | Update the OSPF NSSA option specified in RFC 1587 and submit to IESG for consideration as a Proposed Standard | |
Done | Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard | |
Done | Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited. | |
Done | Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time | |
Done | Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard. | |
Done | Document Alternative ABR implementations and submit ti IESG as an Informational RFC | |
Nov 2003 | Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. | |
Nov 2003 | Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard | |
Nov 2003 | Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard. | |
Nov 2003 | Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic. | |
Nov 2003 | Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850 | |
Nov 2003 | Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard |
RFC | Status | Title |
---|---|---|
RFC1131 | PS | OSPF specification |
RFC1245 | I | OSPF Protocol Analysis |
RFC1246 | I | Experience with the OSPF Protocol |
RFC1247 | DS | OSPF Version 2 |
RFC1248 | PS | OSPF Version 2 Management Information Base |
RFC1252 | PS | OSPF Version 2 Management Information Base |
RFC1253 | PS | OSPF Version 2 Management Information Base |
RFC1583 | DS | OSPF Version 2 |
RFC1586 | I | 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 |
RFC2328 | Standard | OSPF Version 2 |
RFC2329 | I | OSPF Standardization Report |
RFC2370 | PS | The OSPF Opaque LSA Option |
RFC2740 | PS | OSPF for IPv6 |
RFC2844 | E | OSPF over ATM and Proxy PAR |
RFC3101 | PS | The OSPF Not-So-Stubby Area (NSSA) Option |
RFC3137 | I | OSPF Stub Router Advertisement |
RFC3509 | I | Alternative Implementations of OSPF Area Border Routers |
RFC3623 | Standard | Graceful OSPF Restart |
RFC3630 | PS | Traffic Engineering (TE) Extensions to OSPF Version 2 |
RFC3883 | Standard | Detecting Inactive Neighbors over OSPF Demand Circuits |
RFC4136 | I | OSPF Refresh and Flooding Reduction in Stable Topologies |
RFC4167 | I | Graceful OSPF Restart Implementation Report |
RFC4222 | BCP | Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance |
OSPF WG IETF 64 Minutes Scribes: Padma Pillay-Esnault and Acee - OSPF WG Dcoument Status (Refer to presentation) Acee Lindem Acee: Contact me with info on implementations of: - OSPFv3 TE - Multi-area adjacencies Encourage all to read: - OSPFv3 Graceful Restart Need reviewers for: - OSPFv3 Update (RFC 2740 Respin) - OSPF MANET Design Status (Refer to presentation) Tom Henderson Design team work and all discussions will be moved to wider audience. Boeing technical report and GTNetS code available for all to to examine. Justin Dean: Different simulation scenarios/parameters will favor different flooding optimizations. More simulation study is needed to look at unicast route robustness and scalability with motion. Emmanuel Baccelli: Topology reduction shouldn't be a primary goal. Tom Henderson: We did discuss this on the OSPF design list. More discussion of this is included in the Boeing technical report. Russ White: Need to consider reliability in simulations as well as pathological situations. Sue Hares: Simulations do not always match real world results. A case in point is OLSR. We don't know enough yet and should go forward with both flooding optimizations so that they evaluated. Alvaro Retana - Need to decide on scenarios and metrics for evaluation. We need to test mobility scenarios other than wave-point. Tom: Simulation is not the only consideration. Much discussion is included in the technical report. Acee: Discusssion will be taken to the OSPF List. Maybe we should go forward with both algoritms to allow real world deployments and evaluation. Alvaro: 4 different MANET protocols - be good to decide on one. Sue: Need to avoid complexity of algorithms as well. Padma: Feels OSPF list is the best place for discussions. We need to base the decisions both on simulations and reality. Tom: Wide scale MANET deployment and testing is very expensive. - MANET Extension of OSPF Using CDS Flooding (Refer to presentation) Phil Spanola Fred Baker: What is inherently broadcast about a MANET? Frame relay is a prime example of a network that was initially incorrectly modeled in OSPF. Tom: No optimizations in MDR that are specific to broadcast. Broadcast capabilities will be exploited if available. Alvaro: MDRs favor adjacency reduction. However, more neighbors requires more time for MDR selection during which time flooding will not be done. In contrast, MPRs have built-in redundancy during transients. Tom: Both algorithms have comparable costs with respect to selection. - High Mobility Scenarios with MPRs and MDRs (Refer to presentations) Stan Ratliff Tom: What is the timetable for the release of the code and draft update? Random wavepoint is normally the worst case and most agressive scenario. What is the evolution of adjacencies as smart peering is used over time? Acee: Draft and code should be available within week or so after IETF. Russ: Mobility has two components - range and area. What is the spareness of the topology? - OSPF Link Local Signalling as Standards Track (Refer to presentation) Acee Lindem |