Last Modified: 2004-09-07
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 03 | Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. | |
Nov 03 | Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard | |
Nov 03 | Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard. | |
Nov 03 | Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic. | |
Nov 03 | Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850 | |
Nov 03 | 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 |
Open Shortest Path First WG (ospf)
Monday, November 8 at 1300-1500 CHAIRS: Rohit Dube <rohit@utstar.com> Acee Lindem <acee@redback.com> Fairly revolutionary proposal for OSPF v.3 o Document Status 10 minutes Rohit 1 rfc published to be published soon: using an lsa options bit to prevent ? graceful ospf restart scalability draft had couple of comments by IESG to be addressed by authors In AD evaluation: OSPF v2 mib and multi-area adjacency Bill Fenner: went through review, looks like has to go to professional MIB reviewer for extra review Multi-area adjacency: many solutions WG decided to published simplest of them Not sure about implementation Close to last call: - Extensions to OSPF for advertising optional router cap - Advertising a router?s local addresses in OSPF TE extensions - Authentication/confidentiality for OSPFvd WG discussion: - MIT for OSPF v3 - TE extensions to OSPF v3 - Support of address families in OSPFv3 New WG documents: - MT-OSPF: Multi-Topology (MT) routing in OSPF Discussed in San Diego: no dissention Two MT proposals: one for v2 Semantics are different The OSPFv3 multi-topology from an OSPF perspective seems radical o RFC 2740 Respin 10 minutes Acee OSPF v2 RFC has gone through several iterations. We?re now at 2328. OSPF v3 has not had an update Goals: - fix errata that have accumulated - ambiguities - include omissions including features that lack specification - bugs in protocol - deprecate unused features - acknowledge correction contributors Went through some errata: Section 3.4.3.7: intra-area-prefix Appendix: LSA field sizes wrong Ambiguities: Interface instance ID Forwarding addresses and link locals Include omissions: - NSSA additions - input/output processing additions from Nic Neate - SFP calculation handling of LSAs with v6 Protocol bugs: - fix to mitigate the effects of DoS attack using Max Sequence LSAs with high checksum because the checksum in the order above the age (hard to purge) applies equally to v2 and v3 Deprecate: - OSPF external attributes LSA - Reference to site local addresses - MOSPF: may leave it in No questions o OSPFv3 MTR 15 minutes draft-mirtorabi-mt-ospfv3-00.txt Abhay Roy/Sina Mirtorabi Sina (Cisco) Last IETF meeting: v2 This IETF: v3 MTR v3 goal - define multiple independent topology within a physical topology Potential solutions - Instance ID approach - Use integrated approach with existing LSAs: problems Proposed solution - define new LSAs to carry MT information - ignored by old routers - using new TLV style E-inter-area-prefix-LSA, etc. MT-ID filed: 8 bit field present in LSA MT routing operations: - single adjacency formed even if the link participates in multiple topologies - v3 control packets.. Default topology - topology that is built using the exiting LSAs as specified in v3 - defined 2740 compatibililty? NEW LSAs - new lsa payload are TLV based - tlv may contain sub-TLVs e-router LSA has link description TLV Then he presented some of the LSAs, headers If all routers are MT capable, only extended LSAs are used for the default topology Asked to be wg document Acee: once you accept new TLV, you may need to accept unknown TLV - urged everybody to read this and try to do something about ordering of TLVs to add a little more structure than ISIS Sina agreed Alex: not entirely due to v3. need to accept unknown LSA?s so it?s already there Himanshu (Ciena): not following motivation If you get data packet on a single link, how do you distinguish the MT? -Sina: neither mt-isis, v2 or v3 have considered forwarding aspect. It all depends on how you color packet. In those drafts, we?re only looking at control plane Alex wanted to write a draft Used to defined address families Alex: Had a discussion with ISIS guys. There are considerations in the draft. We need to have a document one way of doing this in interoperable fashion. We can take it to routing wg. From the aspect of interop, need to have a single way to demultiplex packets in the case a link belongs to multiple MTs o OSPF Wireless Design Team Status 20 minutes Tom Henderson DT update - met in San Diego and discussions continuing since - agreed on problem statement - several initial agreements on work scope - summarize current technical discussions - next steps DT chartered to produce initial set of v3 extensions for wireless (motivated by draft-baker-manet-ospf-problem-statement) Some extensions would become wg documents and reviewed by MANET and OSPF wg Problem statement: - focus on v3 - compatibility with non-wireless v3 - intra-area extensions only - not focusing on transit network case but not precluded - scaling goal to 50-100 nodes in wireless channel - leverage existing MANET work where possible - use RFC 3668 guidance in dealing with IPR claims consensus reached so far: - agreed to define new MANET interface type rather than a MANET area type (parallel with existing OSPF interface types) - focusing on designing an optimized flooding mechanism for new LSA generation - using acknowledge (reliable) flooding - unacknowledged periodic flooding future extension - hybrid operation also a future possibility Optimizing flooding behavior in broadcast wireless network - reduced # of xmissions to reliably disseminate lsas - Robustness - must make sense within ospf framework-minimize change to ospf Trying to leverage previous work: source-dependent vs. source-independent relay node sets (connected dominating sets in the literature). Considering tradeoffs Joe Macker: MANET WG chair: not necessarily dependent on who sent it but the previous hop Acee: example of source-independent is if you try to create shortest spanning tree for the whole domain - Simulation evaluation of flooding alternatives - in the process of releasing simulation environment for the team - consider whether to define additional wireless optimizations (proposals to make hello message to be differential, to optimize database exchange procedure) or to send them to next work - target draft submission to March IETF Simulation results will be made available Alex: question about unreliable flooding. Wanted the solutions to be in the framework of OSPF design. Tom: Having an un-acked mode of operation may be approximated by Alex: still need to change OSPF mechanism Tom: There have been proposal to change timers Alex: Is the end-result unreliable flooding mechanism? Tom: it would still be reliable with backoff of retransmit timer Alex: may that should be kept in MANET Tom: DT has decided to work on reliable flooding at this time. Rohit: To summarize, flooding is now kept as reliable as OSPF Acee: work is moving along. As a consequence of no proposals for OSPF wireless, we?ll continue with this on top of v3. it seems that this is the protocol that vendors want in OSPF |