Re: Why recalculation from scratch?
Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP> Thu, 15 August 2002 08:45 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 EAA17734 for <ospf-archive@LISTS.IETF.ORG>; Thu, 15 Aug 2002 04:45:54 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006D60F3@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 4:46:38 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109471 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 04:46:32 -0400
Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 04:46:31 -0400
Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CCD985D019; Thu, 15 Aug 2002 17:45:28 +0900 (JST)
References: <E7E13AAF2F3ED41197C100508BD6A328791460@india_exch.hyderabad.mindspeed.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.173711.103390783.yasu@sfc.wide.ad.jp>
Date: Thu, 15 Aug 2002 17:37:11 +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: VishwasM@NETPLANE.COM
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A328791460@india_exch.hyderabad.mindspeed.com>
Precedence: list
Content-Transfer-Encoding: 7bit
VishwasM> Hi Yasu, Hi. VishwasM> The idea is this. When we are under high-congestion, we are VishwasM> in a state where the topology information on the router is VishwasM> incomplete/out of date, doing incremental SPF only further VishwasM> loads the CPU. So instead of doing incremental SPF with VishwasM> every change, we instead club changes and do the entire SPF VishwasM> after a longer period of time, which anyway is best VishwasM> effort(because of databse discrepancies). OK. I understand that SPFs from scratch in a long interval is more prefered than incremental SPFs for each changes. But still wondering if there's any further reason of prefering "SPF from scratch in a long interval" than "incremental SPF *in a long interval*" ... VishwasM> Also check ISO10589, it states that the CPU load for two VishwasM> incremental SPF's can be as much as a single SPF, I dont VishwasM> remember the section though(probably in the Annex VishwasM> somewhere). However I remember conflicting numbers being VishwasM> presented at NANOG. Thank you. I will check RFC1195 (it seems the same as ISO10589). regards. yasu
- 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