2.5.8 Open Shortest Path First IGP (ospf)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://rtg.ietf.org/ospf/ -- Additional OSPF Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-09

Acee Lindem <acee@redback.com>
Rohit Dube <rohit@utstar.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Bill Fenner <fenner@research.att.com>
Mailing Lists:
General Discussion: ospf@peach.ease.lsoft.com
To Subscribe: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1
Archive: http://peach.ease.lsoft.com/archives/ospf.html
Description of Working Group:
The OSPF Working develops and documents extensions and bug fixes to the OSPF protocol, as well as documenting OSPF usage scenarios. The specific protocol work items area listed in the Goals and Milestones section below. Additional work items will require rechartering.
Goals and Milestones:
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
  • - draft-ietf-ospf-ospfv3-mib-08.txt
  • - draft-pillay-esnault-ospf-flooding-07.txt
  • - draft-ietf-ospf-mib-update-08.txt
  • - draft-ietf-ospf-dc-07.txt
  • - draft-ietf-ospf-scalability-08.txt
  • - draft-ietf-ospf-ospfv3-auth-04.txt
  • - draft-ietf-ospf-ospfv3-traffic-02.txt
  • - draft-ietf-ospf-2547-dnbit-04.txt
  • - draft-ietf-ospf-cap-03.txt
  • - draft-ietf-ospf-graceful-impl-report-05.txt
  • - draft-ietf-ospf-af-alt-00.txt
  • - draft-ietf-ospf-multi-area-adj-01.txt
  • - draft-ietf-ospf-te-node-addr-01.txt
  • Request For Comments:
    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
    RFC2328StandardOSPF 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
    RFC3623StandardGraceful OSPF Restart

    Current Meeting Report

    IETF 60 OSPF WG Minutes
    Bill Fenner (Scribe)
    Acee Lindem (Some Editing)

    Refer to the slide prsentations in conjunction with these

    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)

    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)

    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)

    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)

    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)

    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

    Very short on time - No comments

    OSPF IANA Considerations - Kireeti Kompella (Juniper)

    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)

    JP: Twp implementation: routing info LSA & TE info
    Acee: More discussion on this draft needed.


    Document Status
    OSPF WG Wireless Design Team
    Design Considerations for a Wireless OSPF Interface
    Authentication/Confidentiality for OSPFv3
    Multi Topology Routing (MTR) for OSPF
    OSPFv3 Destination Address Filter
    OSPF MPLS Traffic Engineering capabilities