Re: Why recalculation from scratch?
"Manral, Vishwas" <VishwasM@NETPLANE.COM> Thu, 15 August 2002 07:43 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16184 for <ospf-archive@LISTS.IETF.ORG>; Thu, 15 Aug 2002 03:43:47 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006D5E6D@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:45:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109212 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:45:02 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:45:01 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <P9P4PRGN>; Thu, 15 Aug 2002 03:45:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <E7E13AAF2F3ED41197C100508BD6A328791460@india_exch.hyderabad.mindspeed.com>
Date: Thu, 15 Aug 2002 03:47:27 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: Why recalculation from scratch?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Hi Yasu, The idea is this. When we are under high-congestion, we are in a state where the topology information on the router is incomplete/out of date, doing incremental SPF only further loads the CPU. So instead of doing incremental SPF with every change, we instead club changes and do the entire SPF after a longer period of time, which anyway is best effort(because of databse discrepancies). Also check ISO10589, it states that the CPU load for two incremental SPF's can be as much as a single SPF, I dont remember the section though(probably in the Annex somewhere). However I remember conflicting numbers being presented at NANOG. Thanks, Vishwas -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: Thursday, August 15, 2002 12:52 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Why recalculation from scratch? Hi, Related to this, I wonder why the congestion-control draft saying "do not do incremental SPF when congested" (in 4.2.2.4 Reduce the Rate of SPF Computation). Could you give me some more explanation or a reference pointer, authors ? IMHO simply we're just negative to have a lot of state informations, though there are some ways to avoid recalculation from scratch (i.e. incremental SPF calculation). regards. yasu jshen> Bin Liu, jshen> jshen> The first, router does not maintains all information as human does. jshen> the second, each router computes its routing table on its view of network. jshen> When state of some links varies, the logical view of network changes jshen> and the shortest path tree of the graph may become a totally new one; jshen> the third, as link state propagates by relaying hop by hop, it can not jshen> be expected that every router update their routing table simulataneously, jshen> so each time a new link state is received the routing table must be jshen> recomputed jshen> to guarantee the convergence. jshen> jshen> Of course, in a network with thousands of prefix such computing need a lot jshen> of jshen> CPU time but it's just one of the key reasons. IMO, Route flapping and jshen> looping is jshen> the factors attracting more attention. jshen> jshen> Cheers jshen> jshen> Jing Shen
- Why recalculation from scratch? Liu B.
- Re: Why recalculation from scratch? Jing Shen
- Re: Why recalculation from scratch? Yasuhiro Ohara
- Re: Why recalculation from scratch? Manral, Vishwas
- Re: Why recalculation from scratch? satish dattatri
- Re: Why recalculation from scratch? Yasuhiro Ohara
- Re: Why recalculation from scratch? Manral, Vishwas
- Re: Why recalculation from scratch? Liu B.
- L2TP/OSPF Manohar Naidu Ellanti
- Re: Why recalculation from scratch? satish dattatri
- Re: Why recalculation from scratch? satish dattatri
- virtual link transit summary lsa Kishore Kumar Y
- Re: virtual link transit summary lsa Acee Lindem