Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

Zengjie Kou <kouzengjie@HUAWEI.COM> Fri, 30 December 2005 07:28 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsEgJ-0003q8-Kl for ospf-archive@megatron.ietf.org; Fri, 30 Dec 2005 02:28:07 -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 CAA13604 for <ospf-archive@LISTS.IETF.ORG>; Fri, 30 Dec 2005 02:26:55 -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 <12.00007E30@wildebeest.ease.lsoft.com>; Fri, 30 Dec 2005 2:27:35 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95045213 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 02:27:35 -0500
Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 30 Dec 2005 02:27:33 -0500
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA003X6V9OOS@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 15:25:01 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA00HA0V3E6C@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 15:25:00 +0800 (CST)
Received: from k49110 ([10.111.12.97]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISA0000QVLUB4@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 15:32:18 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset=iso-8859-2
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
References: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> <43B45416.4FF846D7@earthlink.net>
Message-ID: <003e01c60d11$28dbb3d0$610c6f0a@china.huawei.com>
Date: Fri, 30 Dec 2005 15:17:57 +0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Zengjie Kou <kouzengjie@HUAWEI.COM>
Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]
To: OSPF@PEACH.EASE.LSOFT.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: base64

Hi,Mitchell

    Please see inline for answers to your questions.

----- Original Message ----- 
From: "Erblichs" <erblichs@EARTHLINK.NET>
To: <OSPF@PEACH.EASE.LSOFT.COM>
Sent: Friday, December 30, 2005 5:24 AM
Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]


> Group,
> 
> If my opinion counts for anything..
> 
> 0) The text has a number of unusal chars.
    
Yes, it may be a question about character set. I will correct it in future verison.

> 1) With a number of routers sending out hellos
>    the moment the interfaces become active, I am
>    not sure of this benefit.. However..
    It economizes a HelloInterval.

> 2) If we are MC hellos, isn't a suggestion of
>    responding with a immediate reply synch
>    hellos. Is this a good thing?

 3) On the previous assumption of MC hellos, and
>    we have say 10 pre-nbrs, does that mean we should
>    send out 10 hellos to each nbr? Our hellos
>    inform each nbr about our state. Does this scale?
>    Can we theorectly be sending out close to 90
>           hellos for 10 nbrs? Each nbr send out a reply
>    to each of their 9 nbrs.
    Your calculation is fit when all router boot first. However,for interface up/dow, it it only 27 hellos.

>    If we wait for the hello interval, the nbrs
>    fields should be filled 1 hello interval
>    after the #1 (bring up hello) was sent with
>    1 hello. Isn't this a good thing?
> 
> 4) With a hello interval separating hellos, we
>    should minimize a hello storm. Isn't this a
>    good thing?
    
> 5) Your section 3. Potential Solution.
>    What is "Fast hello" and "intention"?
    Fast hello: shorten HelloInterval.
    intention: reduce the time to reach the "ExStart".

>   5b) Do we ping pong our hellos if our
>       hello parameters don't match? Assuming
>       we can generate 10k hellos per sec, should
>       we because we are less than 2-way?
>       This is why TCP doesn't ACK and ACK!
>       Or are you thinking about a reply only after
>       validation and acceptance?
    The Immediate hello is performed after hello parameters match each other.

> 6) Your section 5. Immediately replying Hello
>    Does "to this nbr" mean UC (unicast)?
    Yes.

> 7) Your section 5. Immediately ...
>    3f@ After DR is elected...
> 
>    With no hello wait period, aren't you
>    adding a race condition where the first router
>    annouces the DR and the BDR. The SLOWER routers
>    implicitly according to the spec must stop their 
>    election and take the announced DR and BDR as
>    truth in that hello.
>    The other way validates a consensus of a DR / BDR.

> 8) If we ever communicate with ms hellos, your
>    hellos can consume alot of bandwidth for routers
>    that flap?
    when flaping, the immediate hello expediates the link recovery. a few additional hellos will be brought, but it SHOULD consume a lot of bandwidth.

> 9, 10) etc...
> 
> Overall, I think you are addiing alot of complexity
> and NOT allowing the hello pkt to accumalate current
>  state before sending out the next hello. It is possible
> that very small incremental amounts of time are remaining
> via the hello interval timer.
> 
> The hello interval is a minor delay that is agreed to
> be overshadowed by the Waiting time.
> ("Waiting time accounts for 80% to 90% of the total
>   recovery time").
> Thus Amdahls law tells us if we divide a problem
> in half and make 1/2 infinitely fast we will get
> at best a 2x speedup. And you are fixing less than
> 20% of the problem.
> 
> The Waiting time before a DR / BDR election is their
> because:
> * The number of times a wait state needs to
>           be entered should be infrequent.
> * It is only entered if no-one is announcing
>           a DR / BDR, else it should be approx 1/2
>           hello interval time.
> * The wait period assumes that hellos are
>           spread over some time period.
> * Even if 1 hello is lost, all nbr should
>           be known within this time period.
> * The most powerful systems have the largest
>           amount of memory and these memory validations
>           take more time with more memory.
> *etc...
> 
> I see alot of problems and potential problems with
> this suggestion..
> 
> Gasoline for the fire....
> It would make SENSE at least to me, if a DR with max priority
> was voluntarily brought down with a group of other other-routers, 
> to bring it up announcing itself as the DR. This would remove
> 80 to 90% of your IGP convergence time.
> 
 On broadcast and NBMA networks, the time to reach the "ExStart" state 
   is reduced to sub-second by Immediately Replying Hello when DR or BDR 
   exists. In particular, a router interface goes down then up, it is obvious.

Thanks
kou.


 Erblich
> ---------------------
>    
> 
>> Kouzengjie wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> The draft can be found here:
>> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt
>> 
>>  This memo documents an extension of the OSPF protocol to reach
>>    ˇ°ExStartˇą state more quickly. Currently, the OSPF behavior
>> requires
>>    the Hello Packet to be sent between the neighbors every
>>    HelloInterval. This document proposes to generalize the use of
>>    Immediately Replying Hello which could reduce the time required to
>>    reach the OSPF ˇ°ExStartˇą state and  expedite the routing table
>>    convergence.