Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status

sujay <sujayg@HUAWEI.COM> Sun, 18 December 2005 11:41 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enwuh-0008RK-PL for ospf-archive@megatron.ietf.org; Sun, 18 Dec 2005 06:41:15 -0500
Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27902 for <ospf-archive@LISTS.IETF.ORG>; Sun, 18 Dec 2005 06:40:13 -0500 (EST)
Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00006593@wildebeest.ease.lsoft.com>; 18 Dec 2005 6:40:44 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93984306 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 06:40:44 -0500
Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Dec 2005 06:40:44 -0500
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRO00AI3ZI6HZ@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:49:18 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRO000FKZI6QU@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:49:18 +0800 (CST)
Received: from dell60 ([10.18.4.57]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRO0011MZQY51@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:54:36 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID: <000001c603c7$dd0c3da0$3904120a@china.huawei.com>
Date: Sun, 18 Dec 2005 17:10:35 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: sujay <sujayg@HUAWEI.COM>
Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <43A234B2.6000707@cisco.com>
Precedence: list
List-Help: <http://peach.ease.lsoft.com/scripts/wa.exe?LIST=OSPF>, <mailto:LISTSERV@PEACH.EASE.LSOFT.COM?body=INFO+OSPF>
List-Unsubscribe: <mailto:OSPF-unsubscribe-request@PEACH.EASE.LSOFT.COM>
List-Subscribe: <mailto:OSPF-subscribe-request@PEACH.EASE.LSOFT.COM>
List-Owner: <mailto:OSPF-request@PEACH.EASE.LSOFT.COM>
List-Archive: <http://peach.ease.lsoft.com/scripts/wa.exe?LIST=OSPF>
Content-Transfer-Encoding: 7bit

See Inline 
SUJ>

-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee
Lindem
Sent: Friday, December 16, 2005 9:00 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: WG Consideration of
draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR
status


Hi Ashok,

Ashok wrote:

>Hi Acee,
>
>What is saved is the running of the election algorithm, which may be 
>expensive depending on the topology size. Why run it, if it can be 
>avoided?
>  
>
The BDR/DR election is a simple O(N) loop dependent on the number of 
routers on the link

SUJ>Acee, Agree with the math :) , adjacencies are about (N-1), +/- 1 in

Either case.
It cannot be avoided.

I would see the election algo as an O(N), but I were to see the system 
As a whole with (N-1) nodes, that makes the computation O(N*2) !
Else am I missing something?


>I don't see any harm in keeping the BDR status of the restarting router

>intact (excluding the possibility of the DR failing when the restarting

>BDR has not yet come up).
>  
>
No benefit either.


SUJ> Coming up with the BDR or the DR is not as straight process as the 
Algorithm,

I recall this paper on "OSPF Dynamics On a Broadcast LAN" talking about
The actual settling time on LAN's for DR/BDR election.
By M Goyal etc. on this list itself.
http://doi.ieeecomputersociety.org/10.1109/MASCOT.2005.35

Afraid I cannot put the pdf in the mailing list.Here's the
Abstract-"In this paper, we analyze the behavior of OSPF's
interface state machine in a broadcast LAN scenario. We derive
several interesting properties of this behavior that help us
estimate the number of DR elections performed and the time
required as each router on the LAN settles on the DR/BDR identity.
The analytical results are verified using testbed experiments."

To cut the long story short there is a benefit in avoiding it.
Same, Section 3.1.5 in the draft *suggests* to avoid it.

Best Regards,
Sujay


Thanks,
Acee

>Regards,
>Ashok
>
>-----Original Message-----
>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee

>Lindem
>Sent: Friday, December 16, 2005 6:49 AM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: WG Consideration of 
>draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR 
>status
>
><speaking as WG member>
>
>I don't see that preserving BDR status across restarts buys you 
>anything. If there are N routers on the broadcast or NBMA network and 
>the restarting router is preserved, you have to form (N - 1) 
>adjacencies. If you don't, the new BDR has to form (N - 2) adjacencies 
>(since it is already adjacent with the DR) plus the restarting router 
>must form 2 adjacencies. Of course, the adjacency between the new BDR
>and restarting router is counted twice so in both cases you
>form (N - 1) adjacencies on the broadcast or NBMA network.
>Is there something wrong with my math?
>
>Additionally, one could argue that the restarting router already has 
>enough work to do during the graceful restart and you'd rather off-load

>some of the work to a new BDR (all other things considered equal).
>
>Thanks,
>Acee
>
>  
>