2.5.9 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional OSPF Web Page

Last Modified: 2005-05-20


Acee Lindem <acee@cisco.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

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-09.txt
  • draft-pillay-esnault-ospf-flooding-07.txt
  • draft-ietf-ospf-mib-update-08.txt
  • draft-ietf-ospf-scalability-09.txt
  • draft-ietf-ospf-ospfv3-auth-07.txt
  • draft-ietf-ospf-ospfv3-traffic-05.txt
  • draft-ietf-ospf-2547-dnbit-04.txt
  • draft-ietf-ospf-cap-07.txt
  • draft-ietf-ospf-graceful-impl-report-05.txt
  • draft-ietf-ospf-multi-area-adj-03.txt
  • draft-ietf-ospf-te-node-addr-02.txt
  • draft-ietf-ospf-mt-04.txt
  • draft-ietf-ospf-ospfv3-graceful-restart-01.txt
  • draft-ietf-ospf-ospfv3-update-04.txt
  • draft-ietf-ospf-iana-01.txt
  • draft-ietf-ospf-mt-ospfv3-00.txt

    Request For Comments:

    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

    Current Meeting Report

    Open Shortest Path First WG (ospf) - Scribe: Dimitri Papadimitriou

    Wednesday, August 3 at 1030-1230
    CHAIRS: Rohit Dube 
            Acee Lindem 
     o Administriva                                            5 minutes
       - Mailing list: OSPF@PEACH.EASE.LSOFT.COM
         Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1
       - Scribe?
       - Blue Sheets
     o Document Status                                         10 minutes
     o OSPFv3 Update                                           10 minutes 
     o Extensions to OSPFv2 for Advertising Optional           15 minutes
       Route/Link Attribute - draft-miratorabl-ospf-tag-00.txt
       Sina Mirtorabi
     o OSPFv3 Graceful Restart -                               10 minutes
       Padma Pillay-Esnault
     o OSPF MANET Design Team Update and Next Steps            20-30 minutes
       Tom Henderson (Acee presenting)  
     o Issues with existing Cryptographic Protection Methods   15 minutes
       for Routing Protocols
       Russ White or Vishwas Manral
    + Alex MTR Forwarding  
    o) Document status (Acee)

    Progress achieved since Minneapolis meeting (IETF 62)

    • RFC 4126 (OSPF Refresh and Flooding Reduction in Stable Topologies)

    • BCP document on "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance" most implementation do already here tese practices have been documented

    • Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs (draft-ietf-ospf-2547-dnbit-04.txt): blocking on L3VPN

      • Alex: Lots of activity here, with the main OSPF draft there were a lot of comments; lots of back and forth with the authors and changes to the document; then bring back in L3VPN + OSPF WG with the perspective to have enough details concerning interoperability - so it is for review

      • Acee: Invite for review for those familiar with the technology.

    • OSPFv2 Graceful Restart Implementation Report (draft-ietf-ospf-graceful-impl-report-05.txt) waiting on OSPFv2 MIB (normative reference)
      • Alex: Does not have to be listed as normative reference

      • Acee: So going to take it as informative and progress with the document

    • OSPFv2 Management Information Base (MIB) (draft-ietf-ospf-mib-update-08.txt)

    • OSPF Multi-Area Adjacency (draft-ietf-ospf-multi-area-adj-03.txt): not standards track because of lack of implementation
      • Alex: Why is it not implemented ?

      • Acee: Because nobody intends to implement

      • Alex: It is not because it does change the protocol ?

      • Acee: Augmentation but not a change to the protocol

    • Multi-Topology (MT) Routing in OSPF (draft-ietf-ospf-mt-04.txt)

    • Extensions to OSPF for Advertising Optional Router Capabilities (draft-ietf-ospf-cap-07.txt): Last version addresses Adrian's comments

    • Authentication/Confidentiality for OSPFv3 (draft-ietf-ospf-ospfv3-auth-07.txt): Revised I-D needed, before LC new version of the draft

    • Traffic Engineering Extensions to OSPFv3 (draft-ietf-ospf-ospfv3-traffic-05.txt): Last call hung in CCAMP WG as we are going to do this anyway as the WG is going to satisfy ASON requirements with the extensions; so, we are going to add new sub-TLVs to satisfy these requirements (ASON = TE information to control optical switches)

    • Advertising a Router's Local Addresses in OSPF TE Extensions (draft-ietf-ospf-te-node-addr-02.txt): Relationship with ASON but pretty done here

    • IANA Considerations for OSPF (draft-ietf-ospf-iana-01.txt): Useful to have this document in the process and have this as a generic document

    Draft on the table
    • OSPFv3 (OSPF for IPv6) revision (draft-ietf-ospf-ospfv3-update-04.txt): see below

    • OSPFv3 Graceful Restart (draft-ietf-ospf-ospfv3-graceful-restart-01.txt)

    • Management Information Base (MIB) for OSPFv3 (draft-ietf-ospf-ospfv3-mib-09.txt): Trap need to be added

    • Multi-topology routing in OSPFv3 (draft-ietf-ospf-mt-ospfv3-00.txt)

    • AF ALT for support of addresses families in OSPFv3: should move forward

    Pekka Salvoa: a document not product of this WG "Point-to-point operation over LAN in link-state routing protocols" (draft-ietf-isis-igp-p2p-over-lan-05.txt) stuck because normative ref. to IS-IS for IPv6 if we want to have this out of the stack something has to be done like separate document; this is something to consider

    Acee: This function exists and people do it for years but is there much of a rush to make it a separate document ?

    ... no

    Acee: The base spec is implemented for years

    Alex: Check for having informational reference

    o) OSPFv3 Update                                           10 minutes 
    • Work completed

      • many corrections

      • remove reference to site local

      • NSSA support added

      • multiple interfaces per link clarified

      • VL/IF ID clarified

      • Add DN bit

    • Section 2.9 mandates that an OSPFv3 router should not advertize an unknown LSA if the U bit is set to 1 (flood as if known) into stub area; This should be removed in RFC 2740 re-spin limits backward compatibility

      • no corresponding rules for opaque LSAs

      • fact that LSA is flooded implies one router is stub/NSSA understand it

      • ineffective/non-deterministic protection of the database limit

    Alex: is there a message to the ML ?

    Acee: yes, 2 messages but no responses; I think the original intention was an attempt to limit size of the DB but it does not work but as dependent on the topology

    Alex: Problem with the fwd'ing address ?

    Acee: Done

    Alex: There was a problem when mapping the fwd'ding address to the ext-hop address (link-local)

    Acee: Not using link-local address as a fwd'ding address; The problem has been fixed by not advertising the fwd'ing address except for NSSAs; The reason for doing this is that we do not do anything like that in OSPFv2

    Alex: This is not what I mean: when an ASBR advertises an AS-external-LSA with as fwd'ing address the (global) address of a router connected to this ASBR, the calculating router will have to map this address to a link-local address

    Acee: Which is not advertised

    Alex: Indeed, but in IPv6, the next-hop must be link-local and you may not have a routing entry to perform this resolution

    Acee: I do understand the problem but I did not fix it, for NSSA you must have a fwd'ing address

    Alex: Will continue the discussion on the list

    o Extensions to OSPFv2 for Advertising Optional           15 minutes
      Route/Link Attribute - draft-miratorabl-ospf-tag-00.txt
      Sina Mirtorabi
    • carry one or more attribute associated to link/route

    • appl. admin tags in internal OSPF routes

    • other applications can define further attributes
    Router Attributes (RA) Opaque LSA (RA LSA)
    • LSDB Opaque type of 5

    • Attr LS Type (one byte)

    • Unique ID (two bytes)

    • TLV (payload is TLV based)
    Four attributes:
    • Link attribute

    • Inter-area route attribute

    • External route attribute

    • NSSA External route attribute
    Link Attribute TLV (LA-TLV) (TLV Type 1)

    Inter-Area/External Route Attribute TLV (RA-TLV) (TLV Type 2/3/4)

    Definitions of sub-TLV
    • Standard TAG sub-TLV: carry one or more Tags (for a route)

    • Extended TAG sub-TLV: carry one or extended Tags (for a route)

    • MT-ID sub-LTV: carry attributes corr. to multiple topologies as defined in [MTOSPF]
    Generation of RA LSA
    • a router configured to advertise link or route attributes

    • regeneration only if a change occur in the attribute value

    • across area boundary, an ABR will generate
      • area scoped RA LSA

      • AS scoped RA LSA

      • unless specified by local policy

    Backward Compatibility
      • no issues

      • ABR should be able to flood correctly unless AS scope RA LSA

    Ask for WG I-D ... consideration as WG I-D ?

    Acee: Will send a pointer to the list

    Acee: The encoding as sub-TLV for the topology is to find rapidly information and this the first case of nested sub-TLV but would be introduced incrementally; Also, the document suggests a partition of the LSA ID field (Attr LS Type + ID)

    Alex: In this new LSA, is the announced information part of the (original) router LSA ?

    Sina: Yes you are making a reference to this LSA

    Alex: So no substitution to the existing type ?

    Sina: No... but we could - this is why there is no metric field we do not do that for the time being and just do this for the existing LSA

    Alex: We already have the TE LSA for some equivalent purposes

    Sina: Usage of this LSA is to associate one of more attributes to routes

    Alex: What kind of information do you envision as associated to routes ?

    Sina: TAGs can be associated to routing information for filtering e.g. for fast convergence or situation where you want to carry BGP community information; Also in some situations when using IGP and there is a need to carry BGP attributes transparently

    Alex: This is similar to the IS-IS discussion ... referring to the VPN attribute information better define a specific attribute for doing this

    Sina: Here any attribute can be associated to the TAGs

    Acee: TAGs are used for different purposes and this goes already like this today; it is difficult to get advertisement for TAGs

    Alex: TAGs are needed (not questioning the reason for TAGs) but if you have a mechanism to automatically do something you want not necessarily to expose this to the operation

    Acee: Here looking for more flexibility... TLVs do not overload the protocols - People overload protocols.

    Sina: Carry standard TAGs for NSSAs but they carry single TAG and not multiple so would like to be able to carry more than one tag anyway

    o) OSPFv3 Graceful Restart -                               10 minutes
       Padma Pillay-Esnault
    • Common methodology for OSPFv2 and v3

    • OSPFv3 specific considerations

    • OSPFv3 Grace LSA

    • Going forward
      • proposed standard

      • two implementations exist
    • Questions ?
    Acee: This is the document closest for LC as all issues are covered ... so pretty good for PS as well

    Padma: questions ?

    ?: Grace LSA would not require usage of the interface ID

    Padma: There are other LSAs that use the interface ID e.g. TE specific LSA

    Acee: The network LSA uses the interface ID as the LSID.

    Editors note: As does the link LSA.

    o) OSPF MANET Design Team Update and Next Steps            20-30 minutes
       Tom Henderson (Acee presenting)  
    Evaluation of proposal for using OSPF for IGP in MANET experimental protocol and field trial

    Brief History
    • MANET WG Std a set of experimental RFCs

    • PS: draft-baker-...
    • OSPFv3 rather than OSPFv2

    • compatibility with non-wireless OSPFv3

    • intra-area extensions only

    • not focusing on transit network case but should not be precluded

    • scaling goal is 50-100 nodes on wireless channel

    • leverage on existing MANET work were possible

    • use RFC 3668 guidance
    • ...
    Consensus reached so far:
    • working on defining a new MANET interface type rather than a MANET area type

    • focusing first on designing an optimized flooding mechanism for new LSA generations

    • Focus on two active I-Ds

    • ...

    Both drafts focus on selecting more efficient relay node sets RNS for flooding

    Differences between drafts:
    • source independent vs source dependent Connected Dominated Set (CDS)

    • use of hellos or LSA for dissemination of two-hop neighborhood information

    • differential (incr.) hello implementation

    • draft-ogier* proposes reduction of adjacencies formed in dense networks
    Review of optimized flooding draft-chandra*
    Review of draft-ogier*
    Design team evaluation software
    • both drafts have been implemented
    Simulations conducted by Boeing
    • Criteria for evaluation

    • Simulation code and documentation shared with the design team members
    Both techniques reduce the flooding overhead but OSPF was meant to be robust and not necessarily efficient in terms of adj. flooding, etc. Ogier's reduces an extra step in terms of unnecessary routing adjencies

    Next steps:
    • Design team struggle to reach consensus on a single recommended approach

    • proposed to run one more meeting cycles

    • boeing to process or release reporting and reference implementations (and simulator)

    Acee: evaluate the two designs so it would be interesting to look at this Boeing code and I am going to look at it.

    Acee: any comments ?

    o) MT Routing Fwd'ing considerations (Alex Zinin)

    In both ISIS MT and OSPF MT, cases with multiple AF on same interface. In general MT requires separate FIBs and need to map incoming packets to MT/FIBs. Implementations have different demux'ing options such as DSCP or arb. IP field (policy-based) but there is no method which is mandatory so interoperability issue

    Method works but:
    • no standard demux method

    • manual configuration

    • error prone
    No intend to say do not implement a specific method but we could have one mechanism to be implemented as the standard something that could be used for this is e.g. a DSCP mapping or something being MPLS based

    Would like to encourage discussions and drafts

    Tony Li: seems to be unnecessary ... market will do it

    Alex: which market ?

    Tony: the market determines interoperability

    Alex: so ... is interoperability not necessary in your view ?

    Tony: Specify how implementations interoperate is not necessary since the market is going to drive what you are going to implement so you may end with something relevant so no need or irrelevant

    Dave Ward: Nothing to be standardized at the data plane level however something informational around the mapping for topology that would otherwise not form adjacencies - but nothing to standardize at the data plane level as explain usage of DSCP code-points would fall into the problem of standardizing code-points - the best-case scenario: have the flexibility to mark the packets and how operators want to use his

    Acee: I think the usefulness is going to be difficult - we end up with nice names but impossible to have the ISP to implement what we documented here - so it may potentially generate a lot of work without necessarily standardizing the actual usagex

    Alex: Would that not be useful ?

    Acee: I share on Dave's views - some level of information document but this may not be complete

    Chris Hopps: Agree - Tony has a really good point - the interoperability is going to be determined by the providers and the market(ing) is going to drive the different behavior in terms of forwarding

    Dave: we are discussing intra-domain (?)

    Alex: Inter-domain single carrier case is also part of this ... there was a requirement for doing this from the operator side to the vendors

    Tony: At the IETF, we generally standardize the protocols on the wire not their implementation

    Alex: So we agree that we disagree

    Tony: You require a configuration option

    Alex: This is not resulting from a configuration option - here just mappings - anything that is specific in a protocol can potentially be part of the specification but this is not a protocol specification

    Tony: protocol specification is about protocol on the wire; take a look at the history of the IETF documents e.g. configuration of stub areas

    Alex: This is not a good analogy here we are speaking about the consistent forwarding behavior

    Tony: we do not have documents that are specifying forwarding behavior

    Alex: you have to be capable to forward on the longest prefix match

    Tony: this is purely a per-system operation

    Chris: is this not an operator issue ? ... so, it is not up to the spec to fix bad configuration

    Alex: Purpose is to make easier to specify a common profile between different implementations

    Tony: Show hand... more hands showing disagreement

    Dave: We will never be able to limit to this specific case (inter-vendor case)... so we are going to specify a new specific forwarding behavior but what can be standardized is the correlation and the prevention of mis-configurations that can happen, leading to mis-advertisement of specific prefixes but this is outside of the IGP protocol specification and separated from the forwarding behavior asked here

    Alex: A, B, C being the possible behaviors (possible mappings)

    Dave: Yes, we could be marking topology X, Y, Z with an ID with the possible behaviors A, B, C ... but I do not have all the details here


    Acee: Lots of things that are no in the charter that are going to be added in the charter (Annoncement before everyone sneaks off to lunch).
     o Issues with existing Cryptographic Protection Methods   15 minutes
       for Routing Protocols
       Russ White or Vishwas Manral

    Acee: In practice, for OSPFv2 the sequence numbers are not monotically increasing; Usage of router's clock for cryptographic sequence number generation reduces the chance for replay attacks across restarts.

    Vishwas: OSPF spec does not state that the clock should be used for cryptographic sequence numbers.

    Acee: Graceful Restart document recommends this as one way to avoid saving the sequence numbers in non-volatile storage.

    Rich Graveman: This is a good document for someone that understand protocol security but don't understand the routing protocol issues and for someone that understand the security aspects it is now possible to work on required security properties for the routing protocol - example: layer violation have big effect on security or issues due to the message length that may have an impact on choice of security mechanism

    Acee: Please, read this draft and articulate what's missing on the RSPEC list.

    Russ: In RSPEC this may become an informational document and if requirements come out of this it would be interesting to have discussion about the security implication of some of the protocol choices such as for instance usage of multicast


    Document Status
    OSPFv3 Update
    Extensions to OSPFv2 for Advertising Optional
    OSPFv3 Graceful Restart
    OSPF MANET Design Team Update and Next Steps
    Issues with existing Cryptographic Protection Methods