Last Modified: 2004-07-09
| 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 |
| RFC1247 | DS | OSPF Version 2 |
| RFC1246 | I | Experience with the OSPF Protocol |
| RFC1245 | I | OSPF Protocol Analysis |
| 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 |
| RFC3137 | I | OSPF Stub Router Advertisement |
| RFC3101 | PS | The OSPF Not-So-Stubby Area (NSSA) Option |
| RFC3509 | I | Alternative Implementations of OSPF Area Border Routers |
| RFC3630 | PS | Traffic Engineering (TE) Extensions to OSPF Version 2 |
| RFC3623 | Standard | Graceful OSPF Restart |
|
IETF 60 OSPF WG Minutes
Bill Fenner (Scribe) Acee Lindem (Some Editing) Refer to the slide prsentations in conjunction with these minutes. Document Status: - Graceful Restart (RFC 3623) published - Already some ideas on having it less strict about exiting restart but maintaining the same functionality. - Flooding Reduction in Stable Topologies - Has a minor comment pending that should be able to be handled with an rfc-editor note OSPF Wireless Design Team: Tom Henderson: Everyone's waiting for someone else to step forward - what are the expectations wrt deadliens and organization? Acee: We should have someone leading it - not me because of my interests and job responsibilities. first thing should be requirements + problem statement, then there are a lot of ways to handle the problems that are stated. Common thread of all solutions is flooding reduction. Tom: Of the people in the room today, maybe let's meet to discuss next steps. Rohit: This was discussed - had a plan for how this was going to proceed and what the deliverables would be - formalize that and that'll be the design team charter. Note: Change from web agenda: Manet considerations ahead of Manet extensions. Design considerations for Wireless OSPF interface - Tom Henderson (Boeing) draft-spagnolo-manet-ospf-design Summary: - Analysis of overhead; LSU flooding and Ack is dominant ways to characterize simulations independent of specifics to be able to compare different simulations - Presents some results on the improvements of reliable flooding optimizations. - More results on unreliable flooding - LSU flooding is dominant contributor; can reliable optimizations do better than 50%? - Unreliable flooding can provide up to 10x reduction without sacrificing performance (large # of external LSAs are a problem) database exchange optimization may also be important in a frequently partitioning network. - List possible future work: * Flooding algorithm? * DB sync optimizations? * Differential encoding? * Limit adjacencies? Tom: Of the people in the room today, maybe let's meet to discuss next steps. Joe Macker: When you did packet delivery ratios, was it under congested or was loss just from mobility? Tom: Just mobility. Joe: Was this the draft that had the different 2026 boilerplate? Tom: this one was different; we picked it based on our intention to provide information to the design team Joe: would it be a problem if the design team picked up stuff from here? Tom: No Acee: Do you intend to keep with this future work? Should we publish this as informational as a historical record? Tom: We do intend to keep going down these paths, discuss with design team to decide next steps Acee: It's a good piece of work, it may be nice to preserve it. Sue Hares: In the paramaterization, you have neighbor change rate, but the draft seems to have a fixed 20 neighbors; is there a reason for this? Other simulations picked different values. Tom: We picked 20 as a representative number; we've done up to ~100; for a lot of these it was faster to look at different scenarios doing smaller # of nodes; have other work that shows some of the scaling performance as you increase the number of nodes. There's nothing magical about 20. For completeness, maybe we could do more. Sue: Did you go higher than 100? Tom: no Sue: That's number of nodes in the network, right? Tom: Yes. Sue: Why not use link up/down seperately from neighbors up/down? Sue: Some of the larger numbers you might see a different dominant factor Rohit: Let's have this discussion on the list. OSPF Wireless Interface Extensions - Russ White (Cisco) draft-chandra-ospf-manet-ext.txt Russ: Hello may not be a place of huge overhead, but it does pass info that may not be needed to all neighbors; looking at incremental state. Use state sequence #'s to describe current state. Joe: Optimized flooding is something we've been doing for years in manet; are you borrowing? Russ: Yes, this is very similar to OLSR, slightly different overlapping relay set. Acee: Hybrid p2mp but meshed funny. Russ: Yes, it's a single subnet. Acee: It's on one interface, but it's just who you relay to. Russ: Yes. Our assumption is that the device is going to have one "air" interface. Even if there are multiple interfaces, they're all going to work the same way. Alex: With optimized flooding: how do you ensure reliability? Russ: You're still acking, and if you've suppressed your flood but you haven't heard an ack for a little longer than normal then you reflood. Alex: What if you don't have connectivity to the guy you want to hear an ack from? Russ: You wouldn't reflood, since you've lost connectivity. Alex: Worried whether it's provably reliable. Russ: I think so. Acee: If the hello overhead is < 2%, why would we want to mess with it? Russ: We may not want to; we don't know what the real overhead is. if it's so low that it's not worth it then we won't do it. Sue: On slide 6, C doesn't *stop* flooding; he just floods slower? How does C know that B has flooded? Russ: He is on the same broadcast medium, and he will see E's ACK to the packet that it got from B. Sue: If B goes away, will C ever speed up? Russ: As soon as B drops his relationship with E, the hello stuff will catch up; A will learn that B can't reach E so will tell C t to flood. Sue: Timing there is critical. Russ: Alvaro, did our simulation cover that? I don't think we know these numbers. Alvaro: I don't know. We look at the router-LSA, not hellos, so it's convergence time, not hello cycle. Tom: For hellos, is it true that there are 2 aspects changed: differential hellos but also overlaying the relay set selection on hello messages. Russ: Yes. You can do relay set selection on type1s but you've already flooded by that point so you don't save anything in the initial flood. Rohit: This applies equally to tom - purely for the MANET side, how many nodes do you expect to see? Russ: 40-1000. Joe: You can have a channel in an urban environment that fluctuates quickly, you may want some hysteresis to keep links like this from going away. Russ: Yes, we should consider this. Joe: We should talk about this on the design team; it can be disasterous to lose links briefly like this. Uoe: Is there a time the design team can meet? Possible interim meeting? Acee: Russ can sponsor one in RTP :^)! OSPFv3 Authentication Issues/Resolution - Suresh Melam (Nokia) draft-ietf-ospf-ospfv3-auth-04.txt Suresh: Will update draft based on lunchtime discussion with SEC & RTG ADs. An SA per instance is impossible to validate - any instance could use any valid SA, so one SA per link. Should we new/old IPsec drafts? Bill: Should use new because of multicast and replay protection advances. Acee: Problem with instance ids are bad on multi instances: you can use multiple SAs? Bill: But that won't protect SAs from each other. Mukesh: Plus you can't have some instances doing security and some not. Unknown: IPsec can't pick the right SA on outbound with multiple instance on the same interface. Acee: And we thought this was going to be easy! Multi-topology routing for OSPFv2 - Peter Psenak (Cisco) draft-psenak-MT-OSPF-00.txt Peter: Reuse 1583-style TOS LSAs for multi-topology use. Unknown: How does the routing table look? Peter: Depends on implementation; you can have different table per topology or all in one table. Unknown: Sounds a lot like why you go to MPLS in the first place. Acee: The alternative is multiple instances; that's more intensive with memory and processing power. I don't think those are issues with today's networking equipment. Alex: On routing tables: I know why you don't want to say why routing tables are stored. We need to worry about interoperability. If one does one thing and one does another they may not interoperate. Peter: Why? Route lookup should be the same no matter what your data structures. Looking in one table should be the same as looking in multiple tables. Acee: First issue is do we want to do this in OSPF? Alex: Another question is what about forwarding? Do we want standard way for routers to interoperate in forwarding plane? Tom henderson: Supports this becoming a WG document. We did something similar to this and found it useful to do this kind of thing without deploying a full-blown TE solution. Acee: No real opposition, some support, take it to the OSPF WG list to move forward. Padma: There are definitely ISIS multi-topology deployments. Route Attribute Opaque LSA - Acee Lindem (Redback) draft-lindem-ospf-route-attr-00.txt Unknown: Could you clarify - s this just for the next-hop or is it general? Acee: It could be general for other applications as well. Padma: For NSSA, the ABRs need to translate - what if you have several ABRs translating the same type 7 LSA? Acee: Hopefully both would be doing the same translation since they're using the same rules to select the route. If it's a multipath, it's the concatenation of the attributes. Padma: So you could have two nexthops? Acee: Hadn't thought of protection going across an NSSA boundary. Destination address filter - Acee Lindem draft-lindem-ospfv3-dest-filter-00.txt Very short on time - No comments OSPF IANA Considerations - Kireeti Kompella (Juniper) draft-kompella-ospf-iana-00.txt Kireeti: RFC 2328 doesn't have an IANA considerations section; This document goes through each number space and creates registries for them - included space for standards, experiments, private. Coming up with more when other standards bodies are using OSPF for different purposes. We need more rigor in allocating code points and a point of control. This is our "take back our protocol" program (Analogous to "take back the neighborhood"). Acee: Some codepoints you can't allocate without standards action and remain compatible. For example, there is no protocol handling for undefined link types in a router LSA. OSPF TE Capabilities - JP Vasseur (Cisco) draft-vasseur-ospf-te-caps-00.txt JP: Twp implementation: routing info LSA & TE info Acee: More discussion on this draft needed. |