2.5.6 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-14

John Moy <john.moy@sycamorenet.com>
Acee Lindem <acee@redbgraphics/.com>
Rohit Dube <rohit@xebeo.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@discuss.microsoft.com
To Subscribe: http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?SUBED1=ospf&A=1
Archive: http://discuss.microsoft.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
MAR 03  Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard
MAR 03  Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited.
MAR 03  Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time
MAR 03  Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic.
MAR 03  Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard.
MAR 03  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  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-katz-yeung-ospf-traffic-09.txt
  • - draft-ietf-ospf-abr-alt-05.txt
  • - draft-ietf-ospf-ospfv3-mib-05.txt
  • - draft-pillay-esnault-ospf-flooding-04.txt
  • - draft-ietf-ospf-mib-update-05.txt
  • - draft-ietf-ospf-dc-06.txt
  • - draft-ietf-ospf-hitless-restart-06.txt
  • - draft-ietf-ospf-scalability-02.txt
  • - draft-ietf-ospf-ospfv3-auth-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

    Current Meeting Report

    Open Shortest Path First WG (ospf)
    Monday, March 17 (13:00 - 15:00) 
    Reported by: Dimitri Papadimitriou
    CHAIRS: Rohit Dube  <rohit@xebeo.com> 
            Acee Lindem <acee@redbgraphics/.com>
    Agenda Bashing                                 5 Mins
    MIB Update                                    10 Mins  Dan Joyal 
    OSPF as the PE/CE Protocol in BGP/MPLS VPNs   10 Mins  Eric Rosen
    Support of address families in OSPFv3         15 Mins  Abhay Roy
    WG document status                            10 Mins  Chairs
    WG Charter Update                             15 Mins  Chairs
    Meeting minutes:
    Agenda Bashing                                 5 Mins
    1) MIB Update (10 Mins): Dan Joyal (Acee Lindem)
    OSPF MIB Status (Dan Joyal, discussed by Acee Lindem)
    o OSPFv2 MIB:
      Latest version -05.txt (Nov'00)
      Pending updates:
      - Add support for Graceful Restart
      - Add General group object for configuring reference bandwidth
      - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from 
    read-write to read-only
      - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable 
      - Add external route tag object to 
    ospfAreaAggregateTable for NSSA (RFC 3101)
      - Add configuration support for detecting inactive neighbors over DC
      - Change status of RFC 1850 compliance and conformance groups to 
    Acee Lindem: respond and then WG last call (before the next ietf 
    o OSPFv3 MIB:
      Lastest revision is -05 (Apr'02)
      Pending updates:
      - Add support for Graceful Restart
      - Add General group object for configuring reference bandwidth
      - Add General group counter object for External LSAs (for database 
      - Add external route tag object to 
    ospfv3AreaAggregateTable for NSSA 
      - Add configuration support for detecting inactive neighbors over DC
      - Add instance ID object to virtual interface entry
      - Remove LSA type enumerations from LSDB tables because OSPFv3 
    supports unrecognized LSA types
      - Add object to LSDB table to indicate whether the LSA is locally 
    Acee Lindem: respond and then WG last call (before the next ietf 
    2) OSPF as the PE/CE Protocol in BGP/MPLS VPNs (10 Mins): Eric Rosen
    o Overview: Scenario (Customer with multiple OSPF sites)
      - Service Provider connects sites over a shared bgraphics/bone
      - Not with tunnels but by using BGP to distribute customer routes from 
    site to site
      - Use of BGP is transprent to customer, SP converts BGP routes to OSPF 
    (type 3, usually)
    o Topology view (see slides, discussing CE and PE definitions)
      Note: Eric also explains the problem under consideration, the 
    difference betweeen BGP and OSPF (no ASPath send accross CE-PE link) 
    defining the need for loopfree exchanges. 
    o Route Distributions:
      - PE -> CE: Type 5 LSA (ASBR): use tag for avoiding looping 
      - PE -> CE: Type 3 LSA : LSAs can start to loop around
      => Looping can happen with LSA Type 5, or with LSA Type 3 exchanged over 
    PE-CE area 0 links.
    o Proposed Solution (to prevent from looping) 
      - LSA Options field bit set when PE sends LSA's to CE
      - Do not generate BGP updates when PE receives LSA's from CE with bit set
     - Acee Lindem: we have now 3 methods for loop avoidance: Route Tag, DN Bit 
    and for Intra-Area link (sham links)
     - Eric Rosen: route tags can be  eliminated in favor of the DN bit, but 
    sham links cannot be.
     - Acee Lindem: Thus we would have two preferred methods: DN bit and sham 
     - Eric Rosen:  DN bit applies only to type 3/5 LSAs.
     - Acee Lindem: The DN bit proposal will be revisited during the OSPF WG 
    charter discussion (note: see also below)
    3) Support of Address Families in OSPFv3 (15 Mins): Abhay Roy
    o Overview: 
       - What do we have today in OSPFv3 specification
       - What does this draft propose
       - What does this draft introduce
       - Introduction of the capability in OSPFv3
       - Interaction with non-AF capable routers
       - Conclusion
    o Problem Statement: What do we have today in OSPFv3 specification
       - Router and Network LSAs carry only topology information
       - Only IPv6 address family is currently defined 
       - IPv6-bit defined in Options field (can be used to include or 
    exclude a node in IPv6 address-family)
    o What does this draft propose:
       - Enhance the per node support of AF to per link support to allow a link 
    to be included or excluded explicitly in a given address-family
       - To be used during SPF in order to have incongruent AF topologies
    o What does this draft introduce:
       - A new bit (AF bit) in the Options field in order to support this 
    feature (so routers supporting this draft must set this bit)
       - An unused field in the Router-LSA is defined with Address 
    Familiies per link
       - AddressFamiles field is defined as:
         . each bit corresponds to an address-family (for the time being, only 
    the v6 AF bit has been defined)
         . v6 AF bit must be set when a link participates in IPv6 topology 
    otherwise it must be cleared
         . note: when a link participate in more than one AF, all of the 
    corresponding bits will be set
       - A new LSA called AF-Functionality-LSA is defined to carry bits for 
    each address families (area flooding scope and U bit is set)
         note: not needed for IPv6 AF (uses these bits from the 
    router-lsa hdr)
    o Interaction with non-AF capable routers
    o Conclusion: 
      - Enhances OSPFv3 address-family support from a per node to a per link
      - It enables incongruent topologies for different 
      - Applications ?
    - Q1 (?): What about routers that do not support this feature ?
    - Abhay Roy: new AF capability only available when supported 
    (obviously), here the bgraphics/ward compatibility applies to routers that would 
    support this feature
    - Q1 (?): What happens if this capability is only supported on a 
    per-node basis
    - Abhay Roy: you cannot build incongruent topologies
    - Q1 (?): Your proposal doesn't seem to be *so* bgraphics/ward compatible
    - Abhay Roy: (?) 
    - Ghesam: Step towards IS-IS and half-bit with few things missing 
    (metric) here ending with separated approaches - prefix itself carried in 
    different LSA's to be modified on a per family basis, apart from that i 
    don't have any specific issues with this proposal
    - Abhay Roy: we don't have an urgent need for it today (no per link 
    support) and there is no possibility to have it in an easier way
    - Padma: parallelism with M-ISIS, also OSPFv3 does it have to carry IPv4 ?  
    so it seems a bit too advanced with respect to the situation where we are 
    and where want to go
    - Abhay Roy: Proposed implementation uses OSPF options bits, the debate 
    OSPFv2/OSPFv3 and IPv4/IPv6 is orthogonal here, also this feature is 
    useful in case of multicast topologies so it may become important in the 
    - Rohit Dube (to Abhay Roy): we allow for support of IPv4 in OSPFv3 and 
    multicast with this new capability, do you see any other 
    application(s) ?
    - Abhay Roy: IPv6/Multicast may require new topology, also other address 
    families support than IPv6 might be needed ? but here the objective is to 
    enhance this capability from a per node to a per link 
    - Q2 (?): this capability is useful if you don't use the IPv6 
    proposal, thus suggest to wait for the first application before moving with 
    that; but moving forward seems to be a bad choice at this point in time
    - Abhay Roy: agree, if we wait too long, new developments may need this and 
    the per link capability is the real motivation behind
    - Rohit Dube: if needed better sooner than later but since we don't have any 
    application why bother to include this feature now ?
    - Acee Lindem: mentions another problem (using RFC 1793, as example) where 
    the bgraphics/ward compatibility issue required more code than the real 
    feature, this aspect must also be taken into account when evaluating the 
    present feature
    4) WG document status (10 Mins): WG Chairs
    o RFC 3101 - Open Shortest Path First (OSPF) "Not-So-Stubby Area" (NSSA) 
    Option is now published 
    o Traffic Engineering Extensions to OSPF Version 2: IETF wide last call 
    completed. Decision to defer IANA update should allow publication but it 
    will published at some point in time
    o OSPF Hitless Restart has completed the WG last call and will be 
    udpated with clarifications based on the received comments (2 major 
    comments - see mailing list - will be addressed in this update) 
    o Detecting Inactive Neighbors over Demand Circuits - WG Last Call is 
    completed and document submitted to IESG
    o Alternative OSPF ABR Implementations is in the RFC Publication Queue
    o OSPFv2/v3 MIBs both to be refreshed with additional MIB variables
    o Draft-ietf-ospf-scalability-02.txt should focus more on 
    implementation rather than simulations (note: suggest a shorter title)
    o Authentication/Confidentiality for OSPFv3 
    (draft-ietf-ospf-ospfv3-auth-00.txt) requires more substantive 
    discussions to move forward
    o TE extensions for ospfv3 
    (draft-ishiguo-ospf-ospfv3-traffic-02.txt) item added to the charter and it 
    will become a WG document (we have a clear consensus through the ospf 
    mailing list)
    - Rohit: Any comments ? Any other issue on the drafts and their status ?
      Note: no reactions or comments from the room/group
    5) WG Charter Update (15 Mins): WG Chairs
    o OSPF as a PE/CE Protocol in BGP/MPLS VPNs 
      - Rohit Dube: PPVPN WG works on OSPF for a while now, the 
    recommendation here is to make it as part of the OSPF WG charter. Any 
    comment from ppvpn participating people?
    o Support of Address Families in OSPFv3 
      - Note: discussion seems a bit pre-matured, no comments
    o Optional Router capabilities 
      - Kireeti Kompella: it seems that we take the proposed drafts and 
    include them in the charter rather than producing drafts from charter 
      - Rohit Dube: agrees 
      - Kireeti Kompella: gives examples such as AF families coverage and 
    multiple topologies 
      - Acee Lindem: DN bit is to be added in the charter ? any objection ?  
    anyone opposed ? Not an overhwhelming interest but due to the 
    interaction with the PPVPN WG this item might come into 
      - Kireeti Kompella: Charter should say we want to interface with PPVPN WG 
    since also sham links and others specific proposals related to the PPVPN WG 
    are currently under discussion, so PPVPN WG does some work asking some 
    change to OSPF. 
        Kireeti argues in favor of larger charter items coverage rather than 
    specific items to be covered 
      - Rohit Dube: work items listed are managed and this does not go 
    against inclusion of larger items within the charter of the OSPF working 
      - Alex Zinin: agrees with the relevance of the Kireeti's 
    intervention, for the OSPF WG to extend the charter, the OSPF WG first 
    needs to be in agreement that the group wants to extend than charter and 
    then bring it to the IESG
    o OSPF flooding and refresh reduction in stable topologies 
      - Rohit Dube: OSPF Flooding reduction in stable topologies, either we 
    keep it or leave it?
      - Padma: sent an update which addresses comments received from 
    Acee/Alex and she wants to see it going on and moving forward
      - Rohit Dube: for a couple of documents we want to be a bit more strict 
      - Acee Lindem: target as PS initially, now it seems that 
    informational is more appropriate 
      - Padma: i am open to any proposal, it could be a proposed standard 
    since not invalidating OSPF and just want to go forwad and close this item
      - Acee Lindem: implementation are available, as opposed to DC we 
    propose here to go for informational (this i-d doesn't really build 
    something new on top of RFC 1793)
      - Alex Zinin: pointing to this discusion, some discussions with SP's show 
    that they are concerned with this draft that proposes to disable any LSA 
      - Padma: only LSA refreshes are disabled by the Do Not Age (DNA) bit, LSA 
    triggering still occurs independently of the DNA bit setting
      - Alex Zinin: LSA flooding rules shouldn't be stopped unless LSAs goes 
    over the DC link, this method is not for application in case of 
    "normal" (i.e. non-DC) link
      - Padma: we will take this discussion offline
      - Alex Zinin: DNA bit applicability won't go any further, all 
    interfaces are DC interfaces so only flooded to the nearest neighbor 
      - Acee Lindem: applicable if there are DC links otherwise not further 
    flooded, agrees to take the discussion on the mailing list
    o Bgraphics/ to Optional Router capabilities 
      - Acee Lindem: is there a consensus to move forward with this item ?
      - Acee Lindem: seems there is a disagreement until really needed (Acee 
    also indicates that he is co-authoring this i-d but mentions that he sees 
    one application for this i-d being the Path Computation Server - PCS) 
      - Kireeti Kompella: PCS should be seen "as part" of the CCAMP WG 
    charter but is not there today since we need first to include 
    inter-area routing in the CCAMP WG charter; at that point PCS approach 
    might be seen as a potential item
      - Rohit Dube: we wait until the CCAMP WG decides, so OSPF WG won't take 
    any decision for the time being
      - Jean-Philippe Vasseur: MPLS WG also deals with the management of TE 
      - Rohit Dube: then let's wait until MPLS working group decides
      - Rohit Dube: do we have any other option than 1) wait for 
    CCAMP/MPLS WG outcomes or 2) define the capabilties that some 
    application would use in the future
      - Acee Lindem: anybody else than the authors is interested in this i-d ?
      - Rohit Dube: it seems there is a very weak interest at this point in 
    o Bgraphics/ to Support of AF in OSPFv3
      - Rohit Dube: same question for the Support of AF in OSPFv3. Poll for 
    people that would like to see this item as part of the woking group 
      Note: this i-d doesn't seem to receive a lot of support from the group to 
    work on this item 
    o Bgraphics/ to Optional Router capabilities 
      - Rohit Dube: same question for the IGP Capabilities. Poll for people 
    that would like to see this item as part of the woking group charter ?
      Note: no consensus on draft-raggarwa-... (due to room silence)
      - Rohit Dube: discussion on the mailing list will start once bgraphics/ from 
    this IETF meeting
      - Acee Lindem: meeting is adjourned


    OSPF MIB Update
    OSPF as a PE/CE Protocol or MPLS/VPNs
    Support of Address-family in OSPFv3
    OSPF Document Status
    OSPF Charter Update