Current Meeting Report
Jabber Logs

2.5.5 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/24/2002

John Moy <>
Routing Area Director(s):
Bill Fenner <>
Alex Zinin <>
Routing Area Advisor:
Bill Fenner <>
Mailing Lists:
General Discussion:
To Subscribe:
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:
JUN 96  Complete OSPF for IPv6 specification and submit to IESG for consideration as a Proposed Standard.
JUN 96  Document current usage, update OSPFv2 and submit to IESG for consideration as a Standard.
DEC 96  Submit Internet-Draft on ISPF extensions of IPv6 to IESG for consideration as a Proposed Standard.
DEC 96  Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard.
JUN 97  Update OSPF for IPv6 based on implementation experience, and submit to IESG for consideration as a Draft Standard.
Done  Gather operational experience with the OSPF protocol and submit the document as an Informational RFC.
Done  Design the routing protocol, and write its specification.
Done  Develop multiple implementations, and test against each other.
Done  Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC.
Done  Obtain performance data for the protocol.
JUN 98  Submit OSPF for IPv6 to IESG for consideration as a Standard.
SEP 01  Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited.
SEP 01  Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time
SEP 01  Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic.
OCT 01  Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850
OCT 01  Update MOSPF specification with bug fixes and changes required by RFC 2328. Submit to IESG as Draft Standard
JAN 02  Develop pruning support for MOSPF, allowing it to be used in a transit multicast domain and with IGMPv3. Submit to IESG as Proposed Standard
JAN 02  Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard.
JAN 02  Develop mechanisms to reduce OSPF flooding traffic in highly connected network topologies. Submit to IESG as Proposed Standard.
  • - draft-ietf-ospf-nssa-update-11.txt
  • - draft-ietf-ospf-mlinks-03.txt
  • - draft-katz-yeung-ospf-traffic-06.txt
  • - draft-ietf-ospf-abr-alt-04.txt
  • - draft-ietf-ospf-ospfv3-mib-05.txt
  • - draft-pillay-esnault-ospf-flooding-03.txt
  • - draft-ietf-ospf-mib-update-05.txt
  • - draft-ietf-ospf-hitless-restart-02.txt
  • - draft-ietf-ospf-scalability-01.txt
  • - draft-ietf-ospf-5to7-01.txt
  • Request For Comments:
    RFC1131 PS OSPF specification
    RFC1245 I OSPF Protocol Analysis
    RFC1248 PS OSPF Version 2 Management Information Base
    RFC1247 DS OSPF Version 2
    RFC1246 I Experience with the OSPF Protocol
    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
    RFC2329 I OSPF Standardization Report
    RFC2328StandardOSPF Version 2
    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

    Current Meeting Report

    OSPF WG meeting - Thursday 22nd of november - 15:00-17:00
    Reported by: Dimitri Papadimitriou
    Document status (Acee Lindem and Rohit Dube):
    - RFC 3101 (Not-So-Stubby-Area) currently in final RFC editorship
    - Traffic engineering extensions to OSPF v2 (a.k.a. OSPF-TE) passed the 
    working group last call (completed) - IETF wide last call to be issued 
    - Hitless restart - 04 version to be issued soon. Expect to have WG last 
    call on this version.
    - Detecting Inactive Neighbors over OSPF Demand Circuits 
    (draft-ietf-ospf-dc-05.txt) is pending and is pending wg chair 
    - OSPF Refresh and flooding reduction in stable topologies 
    (draft-pillay-esnault-ospf-flooding-04.txt) needs a couple of edits but no 
    significant changes.
    - Alternative OSPF ABR Implementations 
    (draft-ietf-ospf-abr-alt-05.txt) in the comment cycle, it is pretty much 
    done and the last call will be issued pretty quickly
    - mib-update-05.txt - May want to add the graceful restart 
    Agenda bashing
    - Acee Lindem: Propose to move hitless restart after Kireeti 
    - Kireeti Kompella: Agrees
    On the Agenda:
    1) Rahul Aggarwal (10 Mins): Extensions to IS-IS and OSPF for 
    Advertising Optional Router Capabilities 
    Several changes to this i-d since the last meeting.
    1. Review of the motivation and benefits
       - MPLS-TE (and related) capability discovery mechanism 
       - Network management and trouble shooting options are not 
    extensible thus something generic needed
    2. OSPF router information LSA
       - Optional router information LSA of type 4 and opaque ID 0
       - Format of the TLV's in the body of the router info information lsa is 
    the same as the TLV format used for the TE LSA's
       - Optional TLV must be included as the router capability sub-TLV 
    (flags representing the capabilities), sub-TLV allows for adding 
    additional information flags in the future depending on the needs
    3. Router capability bits
       - see i-d
    4. Conclusion
       - Application through router local policy
       - Flooding scope dependent on application
    Acee Lindem: LSA option bits limited thus to be extended with the 
    Rohit Dube: No mailing list comments so far. How will this fit into the 
    charter? Right now there is not a specific item.
    Rahul Aggarwal: Proposal is made here to pass some information through the 
    use of opaque LSA.
    Alex Zinin: Which part of this work is within the charter? 
    Thus confrontation of this work wrt to the charter needs to be covered in 
    addition to an IANA consideration section.
    Rahul Aggarwal: Agrees
    Alex Zinin: FIFO allocation better std based with expert review before the 
    codepoint allocation by the iana (no arbitrary stuff) experimental values to 
    be also considered here.
    Tom Petch: Negotiation before exchange these opaque LSAs?  as a first 
    Rahul Aggarwal: Usage is a local matter, and also avoids the use of 
    Dimitri Papadimitriou: What are the TE mesh groups mentioned in this i-d? 
    What is behind traffic-engineering?  Are we sure that the underlying 
    concepts are well cooked?  What are the relation with TEWG, the current i-d 
    covers one of the application of TE, but generic mechanism can also be 
    considered that overlaps with GMPLS-OSPF.
    Rahul Aggarwal: Troubleshooting and specific application such as path 
    computation server, may need additional work.
    Alex Zinin: Refers to the previous comments made during the previous 
    meeting it seems that other WG participants prefers the usage of other 
    mechanism to deliver such capability.
    Kireeti Kompella: Agrees
    Rohit Dube: People that oppose may not necessarily be here
    Rahul Aggarwal: Will send another mail for discussion in order to see 
    where in which direction this i-d has to go after this meeting.
    2) Kunihiro Ishiguro (15 Mins): OSPFv3 Traffic Engineering Extensions          
    - Using the proposed framework, proposes an intra-area TE LSA with 
    function code 10, flooding scope is area wide scope, u bit set to 1, thus if 
    the router does not understand LSA it must be flooded anyway.
    - OSPFv3 TE TLV, katz i-d used as a base. TLV thus the router address and 
    the link TLV are considered here for the OSPFv3 router LSA. 
    Acee Lindem: There is an alternate proposal to be discussed thus 
    comments to come after.
    Alex Zinin: Router id related question - reachable address because it can be 
    signalled thus what are the signalling implication related to the 
    proposed change?
    Kunihiro Ishiguro: Not sure at this moment and depends upon the 
    Kireeti Kompella: Does IPv6 provide a addressable and/or reachable 
    Kunihiro Ishiguro: Depends upon the implementation
    Kireeti Kompella: Take for instance, BGP over ipv6 what do you 
    advertize as the next hop? 
    Acee Lindem: It can be the router-id in IPv4.  
    Kireeti Kompella: Router address TLV has been proposed to sync up ISIS and 
    OSPF topologies, and as used in BGP today (to connect BGP with an 
    incoming LSP request), the missing thing here is that links can be 
    unnumbered and thus the point of the router id (the router address that it 
    identifies) is that it needs to be globally unique or defined as unique 
    wide address or sometimes it may be routable thus the same thing is 
    needed with v6.
    Kunihiro Ishiguro: This comes from the traffic engineering 
    implementation and or BGP, here a "stable IP address is not needed" but for 
    traffic engineering purposes it seems to be.
    Alex Zinin: WRT to OSPFv3 it seems that we change the semantic of the 
    protocol, in OSPFv2, this address is a reachable IP address, in ipv6 this is 
    not the case, thus if things are different they should be kept separate in 
    order to maintain the consistency and the semantic of the ospfv3 
    Acee Lindem: Questions about the semantic of the router-id.
    Kireeti Kompella: This is the router address TLV.
    3) Acee Lindem (5 Mins): OSPF Hitless Restart Update 
    note: version -04.txt posted to list
    - Hitless restart i-d of J. Moy, Acee Lindem acts as editor for this 
    document and has an implementation for the interoperability testing. Padma 
    Pillary-Ensault is also an author with an implementation.
    - Changes from 03->04
      . Grace period restricted to the LSA refresh time
      . Alternative to saving crypto seq numbers in non-volatile storage
      . Alternate help mode termination (ignore LSA changes under 
    configuration control)
      . Always flood to in the case of unplanned restart which is 
    important since a router loses the knwoledge of being previsouly elected as a 
    designated router
      . Remove mospf, from future work and add less conservative helper 
    - Proposed change:
      Add alternative to apply the grace LSA to all neighbor adjacencies for 
    orinating router (Padma Pillay-Esnault). This only applies to the case 
    where there are parallel adjacenncies - appears to be fully 
    compatible as long as the grace LSA is flooded on all interfaces.
    Acee Lindem: Thus ready for last call? Will re-issue the draft for 
    comments and wait a couple weeks.
    Alex Zinin: Interoperability tests available?
    Acee Lindem: Redback is interoperable with Juniper (not tried the Moy's 
    implementation), Force10 also has an implementation.
    Padma: Implementation between Juniper and Force10 tested.
    4) Kireeti Kompella (10 Mins): OSPFv2 Opaques in OSPFv3                      
    1. OSPFv2 compared to the OSPFv3 opaque LSA format
    2. Proposal to migrate OSPFv2 opaque to OSPFv3, Use new OSPFv3 LSA type, 
    everything else remains the same; the LSA ID is the same and the opaque LSA 
    info is the same.
    3. Issue with the backdoor problem - yes this is a backdoor but why it is a 
    4. Related question? Is OSPFv3 for IPv6 (only) or an improvment of 
    OSPFv2? Thus we should be able to run an IPv4 network with OSPFv3?
       - If so OSPFv3 is a superset of OSPFv2
       - If not remove all the IPv4 prefix infromation from v3
       Consider OSPFv3 as superset of OSPFv2
       - Then we can migrate properly from v2 to v3
       - If not all sorts of functions will break during the migration
       - Define a new lsa function for each of the opaque LSA type: one for TE 
    LSA, one for the grace LSA, etc.
       - What's the length of the opaque id? 24 or 32 bits?
         But this would break the migration
    5. Conclusion
       Pros and cons for v2 opaque lsa in v3
       - Pros: Code reuse v3 includes v2, migration
       - Cons: Theoritcal backdoor issue
       Pros and cons for translating opaque lsa one-by-one
       - Pro:?
       - Con: Would make the migration less pragmatic
       Next steps: We need to understand what's this backdoor problem is 
    weight, the pro and cons and make a pragmatic decision (to have an opaque 
    LSA ready code)
    Alex Zinin: Questions about OSPFv3 for IPv4? 
    Acee Lindem: Not described in the current RFC 
    Alex Zinin: Thus not to be used for the arguments?  since this is an 
    orthogonal problem: announce IPv4 information using OSPFv3 does not make 
    Kireeti Kompella: The inverse is done today
    Alex Zinin: Do we agree?
    Kireeti Kompella: Yes
    Alex Zinin: Opaque type? 
    Kireeti Kompella: Opaque LSA, this is a v2 opaque LSA 
    Alex Zinin: Have a single level of numbering
    Kireeti Kompella: This implies to change the code - do you know how long it 
    Alex Zinin: Yes and i try to simplyify the code we use
    Kireeti Kompella: The code to use is very simple, look at the opaque 
    Alex Zinin: What's problem we try to solve?
    Kireeti Kompella: New opaque type in OSPFv3 and useful for OSPFv2 as well 
    since I do not want to change my code for interoperability reasons
    Alex Zinin: No difference between the two proposals, thus which one to 
    Kireeti Kompella: Want to do it once (for all)
    Alex Zinin: With the proposal you grab the function code in OSPFv3, the 
    only difference here is, v2 in v3, by doing that you create an overlap 
    specification space and please think about the implication
    Rohit Dube: OSPFv3 for IPv6 is a different protocol from v2 in terms of a 
    model it should be considered as different protocols.
    Kireeti Kompella: Thus OSPFv3 not used for IPv4
    Alex Zinin: Thus we don't use it for discussion
    Kireeti Kompella: Make a statement, if the protocols are different then 
    state this in the corrresponding document
    Rohit Dube: Could you clarify your point
    Kireeti Kompella: Since IPv4 in OSPFv3 is not specified, I will make the 
    clarification in order to allow for that; by analogy, RSVP can use IPv6 
    identification over IPv4 everything is ready except the OSPFv2 document 
    while people ask this from my side, thus this is a real problem and not a 
    theoretical problem as the backdoor one.
    Alex Zinin: The working group should decide what to do, but Alex's 
    concerns with this approach is that it will create potential problem while 
    not solving the intended problem - thus a cleaner approach should be 
    Acee Lindem: This is not a brand new application thus I agree with Alex.
    Alex Zinin: Things must always be specificed
    Kunihiro Ishiguro: type 9 is already used by v2, 
    Kireeti Kompella: Types 9, 10, and 11 map in the value 22 in v3, meaning it 
    is a v2 opaque LSA, but the backdoor problem is there anyway
    Rohit Dube: This problem will be further discussed on the mailing lists as 
    well the respective merits of the two approaches.
    5) Jerry Ash (10 Mins): Congestion Avoidance & Control for OSPF 
    1. Introduction: Draft addresses the problem of scalability; Evidence is 
    failure experience, vendors analyzing their own OSPF 
    implementations, and analysis of the LSA storms
    2. Background and motivation
    3. Failure experience: failure experience in 4/13/98 in the ATT frame 
    relay network.
    4. Proposed protocol mechanism: Signal a congestion state, to become to a 
    specific OSPF protocol processing during the congestion detection, the 
    neighbors will be notified about the slowdown and adjust the flooding 
    5. Lot's of discussion on the list - is there a problem? We feel there is a 
       Initiate a debate on how to solve the problem, the protocol is 
    complete as it is, and these problems will be resolved by having better 
    implementations but operators asks for interoperable 
    implementations this is the reason for these i-d's.
       Thus proposal to go beyond this and go to a procedure for that 
    purpose? The proposed congestion response is analogous to the helper 
    router response to a 'grace LSA' from a congested router in hitless 
       Concerning the approach of better coding? does it solves the problem but 
    in the mean time we think that the better standard between vendors would be 
    to solve these issues
    Padma: Concerning the protocol extensions, grace LSA is not 
    necessarily applicable since a restarting router is not a 
    (necessarily) a congested router; are these to be considered as real 
    protocol extensions (like for instance the throttling) or just more fine 
    tuned implementations?
    Jerry Ash: The congested router would signal its congestion state before it 
    saturates, this would reduce congestion by slowing down the neighbor LSAs 
    sent to the congested router.  These mechanisms are considered as 
    protocol extensions: the neighbor response to the congestion 
    notification is analogous to the helper router response to the 'grace LSA' 
    from a congested router in hitless restart.
    Rohit Dube: Move discussions after the second presentation
    Acee Lindem: But keep track of the charter concerning the hello and ack 
    6) Gagan L. Choudhury (10 Mins): Explicit Marking and Prioritized 
    Treatment of Specific OSPF Packets for Faster Convergence and Improved 
    Network Scalability and Stability
    1. Basic issue: failures in the network generating sustained CPU usage, LSA 
    storms, and positive feedback loops.
    2. Proposal: Priority for the hello and the ack's the question is how to 
    deliver it, ask for having this as BCP, for instance diffserv 
    codepoints for high priority and another for low priority.
    3. Simulation study: Three priority scenarios, and two network 
    scenarios, tested with 2 LSA scenarios.
       Show graphics on the non-converged  LSAs Versus time as a function of the 
    strength of the LSA storm (one curve for each LSA storm).  There is an 
    upper limit or threshold of LSA storm that the network can live with 
    without causing sustained CPU congestion.
       Show table illustrating that in all cases priority for Hello 
    increases the LSA storm threshold that the network can sustain.  I In 
    addition, if priority is given to LSA Ack as well then the LSA storm 
    threshold is increased even further.  Also, with priority for Hello the 
    adjacency is not declared down even under heavy CPU congestion.
    4. Proposal: Prioritization of Hello and LSA Ack is proposed as a BCP.  One 
    way of doing this would be to use one diffserv codepoint for higher 
    priority OSPF packets and another diffserv codepoint for lower priority 
    OSPF packets.  Another way would be to look at the packet headers of 
    incoming OSPF packets and queue higher and lower priority OSPF packets 
    Gagan Choudhury: Should we move to the next one?
    Acee Lindem: yes
    7) Gagan L. Choudhury (10 Mins) LSA Flooding Optimization 
    Algorithms and their Simulation Study 
    1. How to improve the LSA Storm threshold
    2. Basic issue: in very large networks a
       large LSA storm may cause a sustained cpu congestion.
    3. Flooding algos to be considered: 
       - algo1: LSA flooding over all interfaces
       - algo2: LSA flooding over only one interface for parallel 
       - algo3: Full flooding only at Multipoint relays that are a subset of 
    immediate neighbors
    Alex Zinin: algo3 does not guarantee the reliability of the flooding
       - algo4: flooding only along a minimum spanning tree 
       - algo5: algo2 for non-te (topological) LSA's and 
       - algo5: algo2 for LSAs carrying intra-area topology info and algo4 for 
    "other" LSAs.  A modified algo5  also considered that makes the 
    flooding links for  "other" LSAs survivable under single link failure and  
    single node failure (using dual spanning trees)
    Alex Zinin: We can't use all of them or a selection
    4. Simulation results:
       . Presentation of the five different cases each analyzed with the 
    allowed LSA storm size
       . Observations on the flooding algorithms:
         Algorithm 2 gives substantial improvement over Algorithm 1, 
    Algorithm 3 provides marginal improvement over Algorithm 2, 
    Algorithms 4 and 5 provide substantial improvements over Algorithm 2. 
    Modified Algorithm 5 is in between Algorithms 5 and 2.  Algorithm 4 is not 
    robust under failures and should not be considered.
    5. Conclusion: algo2, algo5 and modified algo5 should be pursued further
    Alex Zinin (as WG member): algo5 doesn't appear to be robust, can you 
    explain in which context you propose it?
    Gagan Choudhury: In algo5 all LSAs carrying topology info would be 
    flooded to all neighbors all the time. "Other" LSAs may not reach 
    destination temporarily in case the minimum spanning tree is broken. They 
    may be reflooded after the minimum spanning tree is repaired.  
    Alex Zinin (as WG member): An ATM switch fails, while the IP router is 
    unaware of the routing topology, how does it work?
    Gagan Choudhury: ATM Network is typically designed to be able to carry 
    traffic under single link and single node failure. Our modified algo5 
    makes the flooding link for "other" LSAs survivable under single link and 
    single node failures. 
    Alex Zinin: Referring to previous mailing list discussion, flooding trees 
    generates problem when a single link fail, there is a lot of topology 
    activity here, raising potential multiple trees.
    Gagan Choudhury: During the failure, basic LSA's can carry the needed 
    Alex Zinin: Which LSA's are flooded? 
    Gagan Choudhury: Full flooding is only for the ones that are strictly 
    needed.  This includes "Router" and "Network" LSAs.  "Other" LSAs are 
    flooded over spanning tree. 
    Alex Zinin: It is not always safe to say there is no topology info 
    exchange with more efficient flooding algo's, resyncing neighbors may be 
    heavy... something equivalent to ISIS
    Acee Lindem: Basic flooding paradigm with proposed techniques seems 
    reasonable but anything beyond this is questionable?
    Gagan Choudhury: Agrees
    Acee Lindem: Explicit marking, as specified in RFC 1812, says all OSPF 
    packets should be sent at Internet Control level. If something new is 
    proposed, it must be precisely specified.
    Gagan Choudhury: Agrees, BCP and explicit marking needs more details
    Rohit Dube: To be a bit stronger, priority of hellos, acks, use of other 
    packet for the reset timer; all of these can be done without any 
    protocol changes, to be abstracted and added as a WG i-d; everything else 
    should be included in a separate document,
    Gagan Choudhury: Agrees
    Jerry Ash: Not only a BCP but also needs for an explicit 
    notification mechanism.
    Rohit Dube: BCP talks about hellos and acks, and this seems to be 
    agreed, everything requiring protocol changes (such as flooding) should be 
    discussed separately.
    Jerry Ash: Proposed to start with the ECN (Explicit Congestion 
    Rohit Dube: Propose a vote concering the ECN
    Acee Lindem: (describing the consensus) Clearly more people against.
    Padma Pillay-Esnault: Understand the congestion problems but most of these 
    are related to bugs and implementation issues, the extensions are not 
    really implementation-based solution since they can generate other 
    problems; thus proposes to take them in offline discussions to be 
    tackled by the implementation.
    Alex Zinin: EC notification and EC detection also needs mailing list 
    discussion, people are afraid of specifying the implementation details, and 
    believe that we don't have to go to these two extremes, (bits on the wire 
    only versus implementation details), Alex would like to open the 
    discussion concerning these very dynamic behaviors.
    Rohit Dube: charter update
    Charter update has been sent out on the list
    Selection criteria are as follows:
    - Rough consensus on the list
    - Technical quality of these i-ds
    - Urgency of the item
    - Charter proposal pending for a bit (queue up)
    Done things:
    - OSPF for IPv6
    - NSSA update
    - OSPF-TE extensions
    To do list:
    - See proposal
    - MOSPF
    - OSPF flooding reduction
    Note: To be reconsidered in case of strong need
    Alex Zinin: IPv6 meeting today on "site local" issues. Site border work not 
    needed for now. 
    Rohit Dube: Will submmit the chrter to these i-ds
    Acee Lindem: New items will be added or removed per evaluation 


    Congestion Avoidance & Control for OSPF Networks
    OSPF WG Charter Proposal
    Congestion Avoidance & Control for OSPF Networks
    OSPF Document Status
    LSA Flooding Optimization Algorithms and Their Simulation Study
    OSPF Hitless Restart
    Opaque OSPFv2 LSAs in OSPFv3
    Traffic Engineering Extension for OSPFv3