2.5.6 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. 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: 2004-09-07


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

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-scalability-08.txt
  • draft-ietf-ospf-ospfv3-auth-05.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-01.txt
  • draft-ietf-ospf-multi-area-adj-03.txt
  • draft-ietf-ospf-te-node-addr-01.txt
  • draft-ietf-ospf-mt-00.txt
  • draft-ietf-ospf-ospfv3-graceful-restart-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)
    Monday, November 8 at 1300-1500

    CHAIRS: Rohit Dube <rohit@utstar.com>
    Acee Lindem <acee@redback.com>

    Fairly revolutionary proposal for OSPF v.3

    o Document Status 10 minutes Rohit
    1 rfc published
    to be published soon: using an lsa options bit to prevent ?
    graceful ospf restart
    scalability draft had couple of comments by IESG to be addressed by authors
    In AD evaluation:
    OSPF v2 mib and multi-area adjacency
    Bill Fenner: went through review, looks like has to go to professional MIB reviewer for extra review
    Multi-area adjacency: many solutions
    WG decided to published simplest of them
    Not sure about implementation

    Close to last call:
    - Extensions to OSPF for advertising optional router cap
    - Advertising a router?s local addresses in OSPF TE extensions
    - Authentication/confidentiality for OSPFvd
    WG discussion:
    - MIT for OSPF v3
    - TE extensions to OSPF v3
    - Support of address families in OSPFv3
    New WG documents:
    - MT-OSPF: Multi-Topology (MT) routing in OSPF
    Discussed in San Diego: no dissention
    Two MT proposals: one for v2
    Semantics are different
    The OSPFv3 multi-topology from an OSPF perspective seems radical

    o RFC 2740 Respin 10 minutes
    OSPF v2 RFC has gone through several iterations. We?re now at 2328.
    OSPF v3 has not had an update
    - fix errata that have accumulated
    - ambiguities
    - include omissions including features that lack specification
    - bugs in protocol
    - deprecate unused features
    - acknowledge correction contributors
    Went through some errata:
    Section intra-area-prefix
    Appendix: LSA field sizes wrong
    Interface instance ID
    Forwarding addresses and link locals
    Include omissions:
    - NSSA additions
    - input/output processing additions from Nic Neate
    - SFP calculation handling of LSAs with v6
    Protocol bugs:
    - fix to mitigate the effects of DoS attack using Max Sequence LSAs with high checksum because the checksum in the order above the age (hard to purge) applies equally to v2 and v3
    - OSPF external attributes LSA
    - Reference to site local addresses
    - MOSPF: may leave it in
    No questions

    o OSPFv3 MTR 15 minutes
    Abhay Roy/Sina Mirtorabi
    Sina (Cisco)
    Last IETF meeting: v2
    This IETF: v3
    MTR v3 goal
    - define multiple independent topology within a physical topology
    Potential solutions
    - Instance ID approach
    - Use integrated approach with existing LSAs: problems
    Proposed solution
    - define new LSAs to carry MT information
    - ignored by old routers
    - using new TLV style

    E-inter-area-prefix-LSA, etc.
    MT-ID filed: 8 bit field present in LSA
    MT routing operations:
    - single adjacency formed even if the link participates in multiple topologies
    - v3 control packets..
    Default topology
    - topology that is built using the exiting LSAs as specified in v3
    - defined 2740 compatibililty?
    NEW LSAs
    - new lsa payload are TLV based
    - tlv may contain sub-TLVs
    e-router LSA has link description TLV
    Then he presented some of the LSAs, headers
    If all routers are MT capable, only extended LSAs are used for the default topology
    Asked to be wg document
    Acee: once you accept new TLV, you may need to accept unknown TLV
    - urged everybody to read this and try to do something about ordering of TLVs to add a little more structure than ISIS
    Sina agreed
    Alex: not entirely due to v3. need to accept unknown LSA?s so it?s already there
    Himanshu (Ciena): not following motivation
    If you get data packet on a single link, how do you distinguish the MT?
    -Sina: neither mt-isis, v2 or v3 have considered forwarding aspect. It all depends on how you color packet. In those drafts, we?re only looking at control plane
    Alex wanted to write a draft
    Used to defined address families
    Alex: Had a discussion with ISIS guys. There are considerations in the draft. We need to have a document one way of doing this in interoperable fashion. We can take it to routing wg. From the aspect of interop, need to have a single way to demultiplex packets in the case a link belongs to multiple MTs

    o OSPF Wireless Design Team Status 20 minutes
    Tom Henderson
    DT update
    - met in San Diego and discussions continuing since
    - agreed on problem statement
    - several initial agreements on work scope
    - summarize current technical discussions
    - next steps

    DT chartered to produce initial set of v3 extensions for wireless (motivated by draft-baker-manet-ospf-problem-statement)
    Some extensions would become wg documents and reviewed by MANET and OSPF wg
    Problem statement:
    - focus on v3
    - compatibility with non-wireless v3
    - intra-area extensions only
    - not focusing on transit network case but not precluded
    - scaling goal to 50-100 nodes in wireless channel
    - leverage existing MANET work where possible
    - use RFC 3668 guidance in dealing with IPR claims
    consensus reached so far:
    - agreed to define new MANET interface type rather than a MANET area type
    (parallel with existing OSPF interface types)
    - focusing on designing an optimized flooding mechanism for new LSA generation
    - using acknowledge (reliable) flooding
    - unacknowledged periodic flooding future extension
    - hybrid operation also a future possibility
    Optimizing flooding behavior in broadcast wireless network
    - reduced # of xmissions to reliably disseminate lsas
    - Robustness
    - must make sense within ospf framework-minimize change to ospf
    Trying to leverage previous work: source-dependent vs. source-independent relay node sets (connected dominating sets in the literature). Considering tradeoffs

    Joe Macker: MANET WG chair: not necessarily dependent on who sent it but the previous hop
    Acee: example of source-independent is if you try to create shortest spanning tree for the whole domain
    - Simulation evaluation of flooding alternatives
    - in the process of releasing simulation environment for the team
    - consider whether to define additional wireless optimizations (proposals to make hello message to be differential, to optimize database exchange procedure) or to send them to next work
    - target draft submission to March IETF
    Simulation results will be made available
    Alex: question about unreliable flooding. Wanted the solutions to be in the framework of OSPF design.
    Tom: Having an un-acked mode of operation may be approximated by
    Alex: still need to change OSPF mechanism
    Tom: There have been proposal to change timers
    Alex: Is the end-result unreliable flooding mechanism?
    Tom: it would still be reliable with backoff of retransmit timer
    Alex: may that should be kept in MANET
    Tom: DT has decided to work on reliable flooding at this time.
    Rohit: To summarize, flooding is now kept as reliable as OSPF

    Acee: work is moving along. As a consequence of no proposals for OSPF wireless, we?ll continue with this on top of v3. it seems that this is the protocol that vendors want in OSPF


    Document Status
    RFC 2740 Update
    Multi Topology Routing for OSPFv3
    OSPF Wireless Design Team update