Re: Why recalculation from scratch?

Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP> Thu, 15 August 2002 07:29 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 DAA15831 for <ospf-archive@LISTS.IETF.ORG>; Thu, 15 Aug 2002 03:29:37 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006D5E67@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:30:55 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109154 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:30:53 -0400
Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:30:53 -0400
Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F06355D019; Thu, 15 Aug 2002 16:29:49 +0900 (JST)
References: <OSPF%2002081423045241@DISCUSS.MICROSOFT.COM>
X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20020815.162132.64931757.yasu@sfc.wide.ad.jp>
Date: Thu, 15 Aug 2002 16:21:32 +0900
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP>
Subject: Re: Why recalculation from scratch?
Comments: To: jshen@CAD.ZJU.EDU.CN
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <OSPF%2002081423045241@DISCUSS.MICROSOFT.COM>
Precedence: list
Content-Transfer-Encoding: 7bit

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