Last Modified: 2005-01-17
| 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 |
|
IETF OSPF WG Notes - March 8th Taken by Ryan Elliot (relliott@cisco.com) 1. Administrivia - Blue sheets, etc. 2. Document status Published: - DC inactive Neighbor Detection RFC Editor Queue: - Using LSA options Bit - Graceful Restart Implementation Reoprt - ReFresh and flooding reduction IESG Review: - OSPF v2 MIB * All issues have been addressed. Needs MIB doctor review. - Prioritized Treatment of OSPF packets * In another revision with comments - Authentication for V3 * Comments for security AD * Authors need to have a look - Multiarea Adjacencies * Awaiting a date on tele-chat. Close to WG Last Call: - OSPFv2 Multitopology Routing Draft - Extensions for advertising optional capabilities * Question: on inclusion of flags. Or do we remove flags? * Question: Do all users advertise capabilities? How does a neighbor trigger someone to look into the flags? 1. Should we include the definition of capability flags 2. Should the informational flags be included at all 3. Can we advertise the capabilities at different levels. * Acee understands issues, they are known issues, and need to be worked over until everyone is happy - OSPFv3 TE Extensions * Not many changes in the last 2 years * Acee has taken over draft Need better/more review: - OSPFv3 Update - OSPFv3 Support for AF's - OSPFv3 Graceful Restart * Might not be so urgent Expired documents - Advertising Local Addresses in TE extensions * This is being referenced by other docs, we need to keep it updated * Methods used in this doc are being used, what can we do here? * Answer: Check w/ the author (already reminded author) to refresh draft * Send an e-mail to list on draft, maybe we can add an author to keep it refreshed. - MIB for OSPFv3 * We are working on v2 first, will get back to it. 3. Handling of unknown Link Types - Acee Lindem for Vishwas Manral Brian Field - Comcast - Handling of unknown link types is not handled in v2 or v3 * there are no deterministic ways of handling * There is the Manral draft, which has behavior defined * 3 things we can do here 1. Ignore 2. Ignore and log an unexpected 3. Reject LSA * Consensure is to ignore unknown types, but want to be conservative what we are going to Add. * Quesion: Do we need to document? (Acee) * Answer: (Alex Zinnin) - Does anyone see a problem? Ignoring will lead to inconsistent routing table, . The only realistic measure is to raise all possible flags. We find unknown because 1. Bug is causing 2. New type of link introduced, but what if we have a network w/ routers which know and don't know link type. Need some type of capabilites negotiation if htere are multiple inconsistent routers. Doesn't think ignore (Option #1) will work. #3 (Reject LSA), not sure there is enough detail to understand consequences. Does it fall in line w/ algorithms? Are we going to stop SPF? We need to drop traffic, so it's not looped, so we don't consume bandwidth. * Acee: there is a section of backwards compatibilities in the draft. there are some holes; If we ignore, what do we do? Could be a 4th option to do nothing since we've gone this long without formally defining. 3. OSPFv3 Multiple Interface on Link - Michael Barnes * 2740 draft - Section that was missing on "Multiple Interfaces to a Link" (Michael Barnes) - Section 3.9 enhancement * Too ambiguous - Original spec didn't answer all questions * Specifices that router should support having multiple interface on same physical link. OSPF v3 carries int ID in hello's, we should use that to recognize received hello packets that were sent out on another int on the router. v3 supports multiple instance ID's, need to ensure that if instances are different thta there is no interference. If instances are the same, then we have multiple interfaces on same link. Each instance would have own adjacencies, link LSA's, etc... One interface would be active, continue to send/recieve packets, other interfaces will monitor hello packets from other int, but won't send packets. Designate "Active" and "Standby" interfaces. * All interfaces must be in the router LSA to be considered in the SPF * Need to generate link LSA for standby interfaces - Need to be flooded over the active interface. Prefixes for standby must be included in LSA's. * If active goes down, there are multiple mechanisms 1. Monitor hello packets on standby - 2. If active is admin brought down, elect standby to become active * During SPF - When examining network LSA, must examine to include all links as next hops. Maybe create a list of links, process * Keeping track of secondary standbys - New state for state machine. A standby state for the interface defined as; 1. Interfaces detects that it's multiple - Triggers link event, puts into standby mode 2. If another interface causes standby - Then standby will transition back to waiting, then trigger interface up event. * Comments - Acee - If we follow 2740, there are steps that are taken care of, and remain backward compatible. - Michael - No change to doc, just clarification, and mechanism to detect multiple interfaces, and the state. 4. OSPF Manet Design Team Status - Tom Henderson - Manet design team - What kind of extension are possible to add to OSPF protocol to enhace performance in MANET environ. - Background * Manet WG standardized experimental RFC's * Can we borrow principles and apply to OSPF? * Maybe define extentions to OSPF for performance * Needs written up in problem statement authored by Fred Baker * OLSR like adaptations were discussed * Charter this design team, meeting informally and on mailing list - Review Ground Rules * Focus on OSPFv3, not v2 * Compat w/ non-wireless v3 * Intra-Area extensions, not on transit network case * Output shouldn't preclude though * Scaling goal is 50-100 nodes * Leverage existing MANET work * Use RFC 3668 guidance for IPR - Consensus * Define a new MANET interface type instead of an Area type. * Not match on current interface types, but there were some that are close, maybe a hybrid approach to what we have * Design optimized flooding mechanism - Simulation proved that LSA dissemination gave too much overhead, which centered the focus here. * Additional optimizations as a lesser priority * Focus on 2 active I-D's - Both drafts focus on selecting more efficient Relay Node Sets (RNS) * Strive to form "Connected Dominating Set" (CDS) * If only a subset of nodes could reflood LSA's, there would be minimal tranmissions - Difference between drafts * 2 constructs - Source Independent vs. Source Dependent - If a node is a CDS, does it forward all LSA's, or a consideration of who send it to you? * Hello's vs. LSA's for 2-hop neighbor info * Ogier draft addresses minimizing # of adjacencies - Review of draft-chandra * Slide 6 on presentation * How is flooding efficient, would all routers downstream need to reflood? no * Protocol dtermines which one-hop neighor would notify the two-hop neighbors * A router will have the two-hop neighbor info to determine * Main difference between this and OLSR is that this flooding process is ack'ed, so it's reliable * Exchange of info is ensured to be successful * Creates a non-active relay, and if no ack it turns active - Preview of draft-ogier * Each router will ensure that their 2-hop neighbor update is taken care of * One difference - If we have a set of "relay nodes" * An algorithm would be run to select relay nodes - regardless of where the info is received from, the flooding will be done. * Terminology is "designated" vs. "backup-designated" router - Design team is evaluating both proposals - * Developed implementatin of Chandra's draft in quagga * Working on implenting Ogier's draft * Next meeting targeting results and decision. * Questions the team is trying to answer - Stability of relay node set selection - Overhead - Robustness of routing - Stratch factor on data and overhead - Runtime complexity * Initial results - Most overhead is due to LSA flooding - Make flooding efficient - Minimize # of LSA'a generated - Chandra's *DOES* reduce overhead by focusing on efficiency - Next steps * Goal to select flooding algorithm by next IETF * Implement Ogier's draft simulation - Focus on optimized flooding - Questions * Question (Rohit): Is it a goal to have a single recommendation between the 2 drafts? - Answer (Henderson): Not explicit goal, but probobly implicit. Trying to drive to 1 recommendation. 4. Manet Extensions using CDS Flooding (Ogier's draft presentation) - Richard Ogier - Richard could not make it, Tom is presenting - How can we find the subset of nodes that will be relays? - Core idea - Generalize router concept in Broadcast environment - Connected dominating set might be a group of nodes, rather than the single one in a broadcast environ. - It has the concept of a backup designated router in the wireless case, we can have "backup" nodes which has adjacencies formed, adding robustness and redundancy. - Algorithm in draft includes concept of CDS - Uses 2 hop neighbor info to elect CDS nodes. - Verify w/router priority and router ID, self-elected as DR, else, a neighbor has a higher priority. - If all neighors cannot be covered by neighboring router, then it will not elect itself and the neighbor will be a dependent neighbor. Backup DR is similar. - 2 variants - 1. Persistent version 2. Non-persistent version - Algorithm O(d2) - - There is a family of CDS algorithms, depending on needs of robustness, if relay set size grows, then tranmission w/ grow. Trading overhead to gain robustness. - Router priority - How do we determine: Capacity, willingness, stability * These can be adjusted in these algorithms * Advertized to neighbors - Adjacencies * Only formed between designated, backup, and Dependent Neighbors. - Comments/Questions: * (Macker) Addition to tradeoffs, how do we test? Can we have fast repair? Dependency on how election occurs, and # of adjencies. What about how can we repair faster, look more into mobility scenarios, and more info nodal failure. * (Henderson) Agree * (???) Clarification on algorithm - Is it distributed, answer, yes. Since differnet nodes will have differnet neighbors, won't different subset's elect different DR's, backup DR's? * (Henderson) Role in adj forming, if a node selects itself as a DR, then announce it it's neighbors, and all dependent routers. * (???) What is router doesn't elect itself as a DR? * (Henderson) take offline to answer * (Macker) Additional dependencies on the algorithm, on the election process. Look into failures - More decisions and re-negotiations. * (Henderson) Agree will be interesting to look at. - Simulation in Mobile Networks * Persistent version of Essention CDS algorithm. * Average # of designated and backup DR's * Number of adjacencies * Details in slides - Conclusion of Simulation * Richard believes CDS is more scalable * Believes DR/BDR generalized naturally and efficiently w/MANETS 5. OSPFv3 Protocol Extension - Acee - History of extension chronology * Added base v2 protocol * Added MOSPF, Type 6 * NSSA Type 7 * Opaque LSA * v3 * Graceful restart * v2 TE * v2 MTR - Options #1 - Continue adding new LSA tyupes for v3, new opaque for v2 #2 - go 100% TLV based approach, like ISIS #3 - Evolve TLV based on LSA types. - Advantages of Option #1 * Potentially smaller LSA's * Advertisements contain only changes * Maintains status quo - Advantages of Option #3 * No sync issues between LSA's. Fewer lookups, less searching * Flexible extensions whi mainaining LSA granularity * Fewer LSA's to manage * Unified approach for protocol extension * Other IGP's won't be able to say were inflexible :) - Vision - Single IP IGP for Enterprise, ISP, and wireless - Questions if #3 selected * What happens to v2 in the near futue, do we revisit that? * How do we control protocol bloat? - Comments/Questions: * (Alex Zinin) Do we redifine existing standards of LSA's, or preserving that, and moving on to new LSAs? * (Acee) Keep LSA's around, then after an area is moved to a new extension, then revisit, at some point the flooding domain can only use the new LSAs. * (Russ White) Looks like we can make v3 better than v2. * (Alex Zinin) Questions/discussion come onto the list. |