2.6.9 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-09-27

Chair(s):

Acee Lindem <acee@cisco.com>
Rohit Dube <dube.rohit@gmail.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 2003  Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard.
Nov 2003  Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard
Nov 2003  Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard.
Nov 2003  Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic.
Nov 2003  Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850
Nov 2003  Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard

Internet-Drafts:

  • draft-ietf-ospf-ospfv3-mib-09.txt
  • draft-ietf-ospf-mib-update-08.txt
  • draft-ietf-ospf-ospfv3-auth-07.txt
  • draft-ietf-ospf-ospfv3-traffic-06.txt
  • draft-ietf-ospf-2547-dnbit-04.txt
  • draft-ietf-ospf-cap-07.txt
  • draft-ietf-ospf-af-alt-02.txt
  • draft-ietf-ospf-multi-area-adj-04.txt
  • draft-ietf-ospf-mt-04.txt
  • draft-ietf-ospf-ospfv3-graceful-restart-02.txt
  • draft-ietf-ospf-ospfv3-update-06.txt
  • draft-ietf-ospf-iana-01.txt

    Request For Comments:

    RFCStatusTitle
    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
    RFC4136 I OSPF Refresh and Flooding Reduction in Stable Topologies
    RFC4167 I Graceful OSPF Restart Implementation Report
    RFC4222 BCP Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance

    Current Meeting Report

    
                OSPF WG IETF 64 Minutes 
                Scribes: Padma Pillay-Esnault and Acee 
    
    
       - OSPF WG Dcoument Status (Refer to presentation) 
         Acee Lindem
    
         Acee: Contact me with info on implementations of: 
           - OSPFv3 TE
           - Multi-area adjacencies
    
              Encourage all to read:
           - OSPFv3 Graceful Restart
    
              Need reviewers for:
           - OSPFv3 Update (RFC 2740 Respin)
    
       - OSPF MANET Design Status (Refer to presentation)
         Tom Henderson
    
           Design team work and all discussions will be moved to wider audience. 
             Boeing technical report and GTNetS code available for all to 
             to examine. 
    
         Justin Dean: Different simulation scenarios/parameters will favor 
             different flooding optimizations. More simulation
             study is needed to look at unicast route robustness and scalability 
             with motion.
    
         Emmanuel Baccelli: Topology reduction shouldn't be a primary goal. 
    
         Tom Henderson: We did discuss this on the OSPF design list. More 
            discussion of this is included in the Boeing technical report.  
    
         Russ White: Need to consider reliability in simulations as well as 
            pathological situations. 
    
         Sue Hares: Simulations do not always match real world results. A case in
            point is OLSR. We don't know enough yet and should go forward with
            both flooding optimizations so that they evaluated. 
    
         Alvaro Retana - Need to decide on scenarios and metrics for evaluation. 
            We need to test mobility scenarios other than wave-point. 
       
         Tom: Simulation is not the only consideration. Much discussion is 
            included in the technical report. 
      
         Acee: Discusssion will be taken to the OSPF List. Maybe we should go
            forward with both algoritms to allow real world deployments and 
            evaluation. 
    
         Alvaro: 4 different MANET protocols - be good to decide on one. 
     
         Sue: Need to avoid complexity of algorithms as well. 
     
         Padma: Feels OSPF list is the best place for discussions. We need to 
            base the decisions both on simulations and reality. 
    
         Tom: Wide scale MANET deployment and testing is very expensive.  
    
       - MANET Extension of OSPF Using CDS Flooding (Refer to presentation)
          Phil Spanola 
    
         Fred Baker: What is inherently broadcast about a MANET? Frame relay is a
            prime example of a network that was initially incorrectly modeled in
            OSPF. 
    
         Tom: No optimizations in MDR that are specific to broadcast. 
            Broadcast capabilities will be exploited if available. 
      
         Alvaro: MDRs favor adjacency reduction. However, more neighbors requires
            more time for MDR selection during which time flooding will not be 
            done. In contrast, MPRs have built-in redundancy during transients. 
    
         Tom: Both algorithms have comparable costs with respect to selection.
              
       - High Mobility Scenarios with MPRs and MDRs (Refer to presentations)
          Stan Ratliff
    
         Tom: What is the timetable for the release of the code and draft update?
    
              Random wavepoint is normally the worst case and most agressive 
              scenario. 
    
              What is the evolution of adjacencies as smart peering is used over
              time? 
    
         Acee: Draft and code should be available within week or so after IETF. 
    
         Russ: Mobility has two components - range and area. What is the spareness
               of the topology? 
       
       - OSPF Link Local Signalling as Standards Track (Refer to presentation)
          Acee Lindem
    

    Slides

    OSPF WG Document Status
    OSPF Wireless Design Team Status
    MANET Extension of OSPF Flooding using a source independent CDS
    OSPF MANET High Mobility Scenarios
    OSPF Link Local Signalling