2.5.7 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 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-16

John Moy <john.moy@sycamorenet.com>
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-07.txt
  • - draft-pillay-esnault-ospf-flooding-07.txt
  • - draft-ietf-ospf-mib-update-07.txt
  • - draft-ietf-ospf-dc-06.txt
  • - draft-ietf-ospf-hitless-restart-08.txt
  • - draft-ietf-ospf-scalability-06.txt
  • - draft-ietf-ospf-ospfv3-auth-03.txt
  • - draft-ietf-ospf-ospfv3-traffic-01.txt
  • - draft-ietf-ospf-2547-dnbit-01.txt
  • - draft-ietf-ospf-cap-01.txt
  • - draft-ietf-ospf-graceful-impl-report-00.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

    Current Meeting Report

    Concludes58th IETF OSPF WG Minutes - Reported by Dimitri Papadimitriou
    Monday November 10 (15:30 - 17:30)
    CHAIRS: Rohit Dube <rohit@utstar.com>  Acee Lindem 
    o Chairs (5 Mins): Agenda Bashing
    o Chairs (10 Mins): WG document status     
    - Published "Traffic Engineering (TE) Extensions to OSPF Version 2" as 
    - Approved for publication "OSPF Refresh and Flooding Reduction in Stable 
    Topologies" - 
    - To be published "Graceful OSPF Restart" 
    - IESG Evaluation/Revised I-D needed: . "Detecting Inactive Neighbors over 
    OSPF Demand Circuits" draft-ietf-ospf-dc-06.txt
    - Awaiting I-D write up . "Prioritized Treatment of Specific OSPF 
    Packets and Congestion Avoidance" - 
    - WG Last Call . "Using an LSA Options Bit to Prevent Looping in 
    - Soon to become WG documents: . "OSPF version 2 Management 
    Information Base" (update of the RFC1850) - 
    draft-ietf-ospf-mib-update-07.txt . 
    "Authentication/Confidentiality for OSPF version 3" 
    - More discussion needed to get WG status: . "Management Information Base 
    for OSPF version 3" 
    draft-ietf-ospf-ospfv3-mib-07.txt . "Traffic Engineering Extensions to OSPF 
    version 3" 
    draft-ietf-ospf-ospfv3-traffic-01.txt . "Extensions to OSPF for 
    Advertising Optional Router Capabilities" 
    - RFC1264 - requirements for protocols and major features . 
    implementation survey
    o Acee Lindem (10 mins): "Graceful OSPF Restart Implementation Report" - 
    This document provides an implementation report for the Graceful Restart 
    extension to the OSPF protocol per RFC 1264 (stating the 
    requirements for a report on implementation experience). 
    - Five vendors have implemented graceful OSPF and have completed the 
    implementation survey.
    - Implementation Differences: . Whether or not strict LSA checking was 
    implemented and, if so, whether it was configurable (note: strict LSA 
    checking indicates whether or not a changed LSA will result in 
    termination of the graceful restart by a helping router.) . Whether a 
    received grace LSA would be taken to apply only to the adjacency on which it 
    was received or all adjacencies with the restarting router. . Whether or not 
    additional extensions were implemented to accommodate other features such as 
    protocol redistribution or interaction with MPLS VPNs 
    - Addition to the OSPFv2 MIB: . 5 new objects to the ospf General Group . 3 
    new objects to the ospfNbrEntry . 3 new objects to the ospf 
    - Acee Lindem: anyone else interested (from the already listed 5 
    vendors) ? 
    -> yes, 2 additional vendors expressed interest and will be included upon 
    completion of the survey.
    o Rahul Aggarwal (10 Mins): "Support of address families in OSPFv3"  
    - Agenda: Motivation, Proposed solution, Design consideration
    - Motivation: Need to carry multiple AF in OSPFv3 (such as multicast IPv6, 
    unicast or multicast IPv4) in addition to IPv6 unicast
    - Proposed solution: . Multiple AFs are introduced in OSPFv3 by 
    reserving Instance IDs and using one OSPFv3 instance for exactly one AF. . 
    Each AF establish different adjacency, have different LSDB and compute 
    different SPT. . Hello processing: to avoid blackholing, hello 
    processing is changed in order to only establish adjacency with the 
    routers that have the AF-bit set in their Options field. . 
    Modification of the semantic of some of the Option field bits defined in 
    RFC2740. . Carrying Prefixes in new AF's: each Prefix has a prefix length 
    facilitating the advertisement of prefixes of different lengths in 
    different AF's (no need to define new LSAs). . Virtual Link (VL): 
    virtual link are not currently supported in other AF's than IPv6 unicast AF 
    (as there cannot be a multihop forwarding based on global IPv6 address or 
    such a path may not exist).
    - AF Design Considerations: . Mmapping an instance to an AF doesn't 
    introduce new mechanisms in the protocol . Minimizes the protocol 
    extensions required and simplifies the implementation. . Presence of a 
    separate LSDB per AF is easier to debug and operate. . Does not change the 
    existing instance, area and interface based configuration model of most 
    OSPF implementations
    - Request to make it a WG document
    - Fred Baker: Agree to make it working group document but concern wrt 
    mobile ad hoc networks (MANET) - does not want to have two neighbor 
    relationships and favor keeping a single instance. Also this solution 
    potentially doesn't address MANET concerns and requirements. 
    - Acee Lindem: everybody here is in agreement that in OSPFv3 has to 
    support multiple AF's so we need to address this issue
    - Fred Baker: In favor of having a single instance (neighbor with a 
    process of transitioning) and doesn't want to see both OSPFv2 and OSPFv3 
    using AF's (doesn't want to have separate protocols for achieving this 
     This is a solution for allowing mutliple address families in OSPFv3 but 
    this solution doesn't necessarily meet the MANET requirements.
     However, agrees to make it a working group document.
    - Hasmit Grover: Not specific to this solution, questions the 
    duplication of information in OSPFv3.
    - Rahul Aggarwal: Not duplicating anything, it is a matter of having two 
    router LSAs instead of one.
    - Hasmit Grover: Still need duplication of topology information and it 
    would not be more complicated to have a single instance for doing this.
    - Acee Lindem: The target was simplication.
    - Hasmit Grover: Doesn't know how much that problem it is, why OSPFv3 is so 
    different ?
    - Rahul Aggarwal: not TLV based
    - Acee Lindem: By comparison, using a single instance for providing this 
    would require more work (than what is proposed here).
    - Rahul Aggarwal: Request for WG document ? 
    - Acee Lindem: I would like to have some more discussion on the 
    proposed solution, but the requirement is acheived - it seems that no one 
    disagrees that this is a requirement for OSPFv3.
    - Acee Lindem: Sense the meeting room for WG document status.
    -> Few people in favor
    - Acee Lindem: Sense the meeting room for having an integrated 
    -> Few people in favor
    - Acee Lindem: WG document status and see how the discussion can 
    - Rahul Aggrawal: This is document is good basis to work on this topic.
    - Acee Lindem: The target for the working group is to come with 
    something simpler.
    o Rahul Aggrawal (10 Mins): "Advertising a Router's Local Addresses in OSPF 
    TE Extension" - 
    - Agenda: Motivation, Problem Statement, Proposed solution, 
    - Motivation: in some cases (for instance in a network carrying VPN and 
    non-VPN traffic it is desirable to setup) CSPF computed MPLS TE LSPs to 
    local addresses of a router that are not advertised in the TE LSAs i.e. 
    loopback and non-TE interface addresses.
    - Problem: OSPF routers can only use CSPF to compute MPLS TE LSPs to the 
    router ID or the local addresses of TE enabled links, of a remote 
       This because: . OSPFv2/v3 TE extensions only advertise the router ID and 
    the local addresses of TE enabled links, of a given router -> other 
    routers cannot populate their TED with other local addresses of the 
    advertising router i.e. loopback and non-TE i/f addresses. . OSPFv2 stub 
    links in the OSPFv2 router LSA OSPFv2 provide stub reachability 
    information but not sufficient to learn all the local addresses of a 
    router (same problem w/ intra-prefix LSAs in OSPFv3)
    - Proposed solution: . Advertise the local addresses in a new node 
    attribute TLV, in the OSPF TE LSA . Node attribute TLV carries the 
    attributes associated with a router - it contains one or more IPv4/v6 
    local address sub-TLVs
    - Acee Lindem: Put the discussion on the mailing list
    - Acee Lindem (to Rahul): You could poll this information out of the 
    router LSA and set that information from the topology?
    - Rahul Aggarwal: Will give the details.
    - Acee Lindem: Ask for comments on the mailing list, this document is a 
    small amount of work since it slightly modifies OSPF-TE
    o Sina Mirtorabi (10 Mins): "OSPF Tunnel Adjacency" 
    - What it is a Tunnel Adjacency (TA): Proposal to solve the intra- 
    area/inter-area path preference, generalization of virtual links, it can 
    force OSPF to take the desire path and it has the on- demand partition 
    - What does TA resolve: intra/inter-area path preferecne, in hub and spoke 
    topology, it saves the cost of adding a new interface, between ABRs, it 
    helps in repairing by avoiding segmented areas
    - How a TA is established: configured as for VL's, and then it is 
    - How data packet is fowarded: . if ABR-ABR link is direct link -> sent w/o 
    encaps . if ABR-ABR link is mutli-hop -> encapsulation needed (doesn't need 
    - TA Configuration/Parameters: . TA is configured between two ABRs 
    attached to the same OSPF area. . Parameters: Tunnel-adjacency Transit Area 
    (TTA) and as for VL's, a TA is identified by Router ID of the other 
    endpoint and its Area ID 
    - TA resolves the VL limitations: . a TA link can belong to any area, . 
    summarization is not affected . TA can't go through stub/nssa area
    - TA has added value features: . TA cost is configurabken . Provides 
    on-demand partition repaitr . Mutliple TA through a given path
    - Padma Pillay-Esnault: Don't see what this adds wrt to tunneling 
    between two ABR's.
    - Sina Mirtorabi: 3 differences, config overhead (IP address), rely on IP 
    address (reachability is done in given area, while tunnel doesn't guide the 
    reachability), and provides automatic partition repair.
    - Alex Zinin: RFC 2328 limits the configuration of the VLs so that they can 
    only transit through non-backbone areas and always belong to the 
    backbone. Among other things this prevents "recursive" VLs, i.e., VLs 
    relying on other VLs.
        The draft relaxes this and suggests that the TA can belong to any area 
    and can transit any area. This opens up a possibility for TA1 that 
    belongs to area A1 to transit area A2 that has TA2. This means that it 
    could be possible for packets to be encapsulated more than once. It seems it 
    could also be possible to have recursive TA resolution, e.g. in the case 
    above, TA2 transiting area A1.
    - Sina Mirtorabi: There was some discussion with Pat sometime ago 
    regarding a scenario and sending Hello over TA ( not making it as DC) help to 
    avoid the problem.
    - Alex Zinin: making it as DC or not should not matter for recursive TA.
    - Sina Mirtorabi: I think this need more thought for recursive TA.
    - Padma Pillay-Esnault: You're making people trying to avoid VL, while 
    topological changes are going to generate re-routing. 
    - Sina Mirtorabi: VL issue is that it was recommended to "not use VL".
    - Padma Pillay-Esnault: Any trigger in its own area is going to 
    generate path re-computation.
    - Acee Lindem: But any intra-area topological change is going to 
    generate path re-computation in one way or another.
    - Padma Pillay-Esnault: But here you may trigger several SPFs and thus end up 
    with several levels of SPF,
    - Acee Lindem: Yes, changes can trigger other changes during re- 
    - Acee Lindem: Express concerns about the requirements, today we have a 
    limitation on an interface belonging to a single area. This 
    requirement can be satisfied by considering the area ID but do we want to go 
    further and have an automated tunneling ?
    - Sina Mirtorabi: Main reason is to have a solution that avoids direct 
    links, otherwise Pat Murphy approach was there to solve this issue.
    - Acee Lindem: But that draft was too complicated.
     -> Take this to the list?
    o Kiretti Kompella (10 Mins): "OSPFv2 Traffic Engineering Extensions for 
    Multi-access Networks" 
    - Traffic Engineering extensions for OSPFv2 for dealing with multi- 
    access networks since the bandwidth attributes in the OSPFv2 TE do not 
    accurately model the available bandwidth across a multi- access 
    - LAN being modelized as a star (modelisation X=DR being one of the 
    router attached to the LAN) but X doesn't generate a TE LSA thus the 
    bandwidth availability (i.e. Unreserved Bandwidth) is not available in the 
    reverse direction (e.g. X->D)
    - Motivation comes from that fact that switches are increasingly the 
    router interconnection of choice and it is fairly trivial to achieve this, by 
    advertizing the reverse bandwidth (i.e. from the DR)
    - Next steps: . Two questions is this useful? Hole in RFC 3630 but also be a 
    requirement from service provider? . Vendors to tell if this a 
    reasonable solution.
    - Acee Lindem: Put the question on the list?
     This is one is a bit more complicated than the previous TE extension 
    (Rahuls), with two more vectors of information.
    - Acee Lindem: Do we want TE to this level of detail that keeps track of the 
    type of switch ? 
    - Dave Ward: There is a requirement to solve the problem, this is also a 
    requirement for which Cisco is receiving input to define such kind of 
    - Acee Lindem: Wonders if this has to be dealt here in the OSPF WG or in the 
    TE WG?
    - (?): any admission control issue ?
    - Kireeti Kompella: Implementation needs a change to use this, backward 
    compatible means that routers by seeing this, they don't pick out (of 
    course they wouldn't be capable of using this); also by using a new TE LSA, 
    router on the LAN would have to understand this TE LSA - concerning CAC 
    issue suggests you read the draft
    - (?): interaction between admission control and RSVP ?
    - Kireeti Kompella: when TE extensions where defined, conclusion was that it 
    doesn't make sense to say how RSVP-TE interacts with this, (this has not 
    been done in OSPF-TE as well) some of the hints to do have been given in the 
    document. Kireeti says it should be clear for the reader.
    - (?): put the information here asks the question of what is the added 
    value of having this information to perform the CSPF.
    - Kireeti Kompella: Information is there to do admission control on the 
    - George Swallow: It works in the fully point-switched case, but not in the 
    case of cascaded switches.
    - Acee Lindem: Put also on the TE WG mailing list
    o Fred Baker (10 Mins): "Problem Statement for OSPF Extensions for Mobile Ad 
    Hoc Routing" 
    - Problem statement for OSPF extensions for mobile ad hoc networks
    - Presentation: 
    - Rahul Aggarwal: High level comment, the argument on why OSPF is 
    suitable is that one MANET network may co-exist with an existing LAN 
    network -> so good to think about extensions 
     The question is if meeting the MANET requirements generate a 
    fundamental change is it not better to have a separate protocol?
    - Fred Baker: INRIA want to have their own protocol, but I want to keep 
    both in one place - the only concern is related to the scalability 
    properties of OSPF - note also the concern on the training issue (so ask if 
    possible to just add a new interface). 
    - Joseph Macker: A bit of history, in essence these protocol 
    requirements seem applicable to OSPF, in addition people deploy and know how 
    to manage it, it has homogeneous properties, and provides prefix 
    summarization - here lot of interesting things in deploying OSPF for MANET 
    networks seems to be stimulated by the development of this (new) problem 
     -> Is there a place for this development and in order to start this we 
    need a problem statement document 
    - Rahul Aggarwal: Arguments seem valid, but seeing the Baker's 
    presentation, it also seems there are lot of changes to be expected.
    - Fred Baker: Not proposing to change the area hierarchy, what we are 
    proposing is adding a MANET (radio) interface which is not behaving as a 
    canonical "OSPF interface".
    - Rahul Aggarwal: We need probably more discussions.
    - (?): how do we address the bandwidth constraint issue?
    - Fred Baker: Turns out there are lot of things to be said here 
    concerning this but we speak here in terms of Mbits .
    - INRIA rep: Disagrees strongly that they were not interested in OSPF, on 
    the contrary INRIA put a lot attention and interest in OSPF, and are 
    clearly also looking at OSPF extensions.
    - Alex Zinin: Refers to an understatement by "simply adding an 
    interface" - before starting to speak about adding an interface, there are 
    lot of things that may be impacted by adding such kind of interface and 
    this even if it looks like very simple, it might not be the case.
    - Acee Lindem: Now OSPF is a general purpose protocol, if we take on all 
    these requirements it will look like very different from what it is 
    today? But I fear that if you take all the military requirements, I am not 
    sure we will end up with the same protocol as we have today - Give the 
    example of authentication in OSPFv3 using shared key multicast model - Thus 
    take into account the military requirements may require a chain of 
    changes from the existing documents.
    - Joseph Macker: We don't speak about military requirements, lot of these 
    are like the existing requirements of an ISP, Baker's proposal was about 
    optimization but wasn't pushed out and here proposal using a kind of stub 
    within OSPF, being less intrusive but also less flexible - it is pretty 
    easy to understand.
    - Sue Harres: Subsets have been worked out by the ISP's and how these 
    changes can be allowed - point to the summarization issue.
    - Acee Lindem: Concurs on fears concerning summarization. 
    - Sue Harres: Router protocols converge very fast today.
    - Acee Lindem: My fear was the change to the basic area hierarchy
    - Fred Baker: What I expect with the area boundary behavior, is that we 
    will summarize at an area boundary as done now, but now information is 
    spread, here departure by having a specific propagation w/i a specific area 
    with longest prefix match first.
    - Sue Harres: Worry about the inter-region flooding, solved if there are 
    multi-admin hierarchy, we have to gauge where we're getting benefits and 
    - Fred Baker: The big problem comes from the exponential explosion in 
    messages and managing that growth (not the summarization).
    - Acee Lindem: there must be a defined hierarchy, the existing protocol 
    will be summarizing when the entity moves from area to another.
    - Alex Zinin: Subsequent convergence in IGP is not the same wrt to the 
    density of the topology - injecting information from an area to another 
    while the majority of the nodes remains in the same area?
    - Rao: This would generate lot of dynamic state changes - using a list of 
    neighbors depending on the region where the entity is located, this list 
    would be pre-configured, but by moving from one region to another are you 
    still keeping the same group of neighbors?
    - Fred Baker: Doesn't understand -> take offline
    - Joseph Macker: Idea with this is to find which WG can host the 
    discussion here, proposes to discuss where people think this item has to go, 
    key thing is to know if this protocol can be implemented using OSPF
    - Acee Lindem: Someone to send the list of drafts so that people can take a 
    look about what we are talking about. 
    *** Meeting is adjourned ***


    Support for Address Families in OSPFv3
    Tunnel Adjacency
    Problem Statement for OSPF Extensions for Mobile Ad Hoc Routing