[vyatta-svn] xorp: Changes to 'xorp_1_4pre'

[Tom Grennan]

 etc/templates/ospfv2.tp   |    8 ++++++++
 ospf/area_router.cc       |   37 ++++++++++++++++++++++++++++++-------
 ospf/area_router.hh       |    6 +++---
 ospf/external.cc          |    2 +-
 ospf/ospf.cc              |    9 ++++++++-
 ospf/ospf.hh              |   35 ++++++++++++++++++++++++-----------
 ospf/xrl_target.cc        |    8 ++++++++
 ospf/xrl_target.hh        |    7 +++++++
 xrl/interfaces/ospfv2.xif |    5 +++++
 9 files changed, 94 insertions(+), 23 deletions(-)

New commits:
commit dbc2255c6e17e59638e3326c689c3be71317d03c
Author: Tom Grennan <tgrennan at vyatta.com>
Date:   Fri Jan 12 19:27:48 2007 -0800

    Patch fix for Vyatta#1622/XORP#372 from <mailto:hasso at estpak.ee>
    
        # HG changeset patch
        # User hasso
        # Date 1168203535 -7200
        # Node ID 9761afd9a6775470bdff02111cf050ac0bee63a4
        # Parent  a954085ebc972676c980af68654a27d46cadf371
        Implement random OSPF LSA refresh timers inspired by Junos.
    
        Instead of refreshing LSA's every 30 minutes, schedule refresh timer
        for every LSA to random value between 45 and 55 minutes. It has two
        important scalability points:
    
        * Don't create refresh storms in the network. Typically router starts
          redistributing a lot of info at once and will refresh all this info
          at once every 30 minutes creating LSA storms in network.
        * Use better aging space fiven by RFC. Using longer refresh timers
          means potentially a lot less OSPF traffic in the network without any
          effect to compatibility etc.
    
        Patch sitting in XORP Bugzilla #372.

commit 90144a7dbfd021fbdbdc62d8a7d0a4d105f370aa
Author: Tom Grennan <tgrennan at vyatta.com>
Date:   Fri Jan 12 19:19:29 2007 -0800

    Patch fix for Vyatta#1622/XORP#576 from <mailto:hasso at estpak.ee>
    
        # HG changeset patch
        # User hasso
        # Date 1168201709 -7200
        # Node ID b3afd4f6d90ab61a7510effff2ff6a24b7b76886
        # Parent  f70319aa7222b241e3a6626a1882b9153115ffab
        Implement configurable subsecond adaptive SPF delay for OSPF borrowed
        from Junos. Although it isn't exactly the same algorithm, it's close.
        My interpretation of "fast schedule" is just slower than Junos one.
    
        SPF is scheduled with 200ms delay by default (configurable between 50ms
        and 1s). If already fourth sequential SPF is scheduled when less than
        1s after prefious SPF (which is sign that topology is unstable),
        algorithm switches to slow delay - 5s (non-configurable). If there has
        been no SPF at least 20s (topology is stable again) delay is switched
        back to stable one.
    
        Patch sitting in XORP Bugzilla #576.

http://suva.vyatta.com/git/?p=xorp.git;a=commitdiff;h=dbc2255c6e17e59638e3326c689c3be71317d03c