Subject: accelerating convergence when ospf starting

From: kouzengjie <[email-masked]>
Date: Wed, 26 Oct 2005 16:32:23 +0800

All,
    OSPF convergence contains neighbor discovery and link state database synchronization.
Neighbor discovery is achieved by hello protocol. Default hello interval is 10s.
Hello packets sent by neighbors is not work on each other.So,covergence time is longer.
If adopting following proposition,then covergence time  is decreased very much on broadcast networks.

    1.Neighbors immediately send hello packet to peer when they receive hello packet from the peer that first sent the hello packet.
    2.Based 1,routers( marked X) that sent the hello packet will repidly receive their neighbors hello packet carrying their peers(X) information.
    3.After 2,DR will start to be elected，building the relation of adjacency and completing link state database synchronization.
    4.After database synchronization,the hello packet will be sent every provious interval each other.

Other disposals about OSPF is the same to RFC 2328.

How about do you think?

best regards,
Kou

---

From: Acee Lindem <[email-masked]>
Date: Wed, 26 Oct 2005 10:07:35 -0400

Hi Kou,

>    1.Neighbors immediately send hello packet to peer when they receive hello packet from the peer that first sent the hello packet.
This can be done. The previous implementation I worked on unicast a
hello back to
a new neighbor..

>    3.After 2,DR will start to be elected，building the relation of adjacency and completing link state database synchronization.
This will not work in all situations - what if both neighbors are just
coming up and neither has
received a hello from the current DR/ BDR? You need to wait for the
BackupSeen or
WaitTimer event. A better optimization (at the expense of a greater risk
that DR churn
will result) would be to allow the wait-timer interval to be
configurable to a value
(hello-interval <= wait-interval <= dead-interval).

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 26 Oct 2005 11:44:11 -0700

Group,

	A faster convergence time may be had, if at least secondary
	routes are calculated, so when a adj is percieved to go
	down, a secondary can quickly be used. 

	This is only assuming
	that the SPF or equiv type calc generates a decent latency
	AND that their are a group of these types of routers wihin
	a localized area, so all make the same quicker convergence.

	Of course, if the passthru data is sporadic in nature and
	their is a lull in the data while the quicker convergence
	is done, no benefits would be seen.

	Mitchell Erblich
	------------------

Acee Lindem wrote:
> >    3.After 2,DR will start to be electedŁŹbuilding the relation of adjacency and completing link state database synchronization.
> >
> >

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 26 Oct 2005 12:26:17 -0700

"A faster convergence time may be had, if at least secondary routes are
calculated, so when a adj is percieved to go down, a secondary can quickly
be used."
The benefit of calculating secondary routes is imaginary because some of
them will be affected by the loss of adjacency that caused the convergence
in the first place. To make it work you'll need to prepare secondary routes
for all possible convergence scenarios. I think that it is obviously does
not scale.

     Regards,
          Greg

                    Erblichs                                                                                           
                    <erblichs@EARTHLI       To:     [email-masked]                                          
                    NK.NET>                 cc:                                                                        
                    Sent by: Mailing        Subject:     Re: accelerating convergence when ospf starting               
                    List                                                                                               
                    <[email-masked].                                                                                  
                    LSOFT.COM>                                                                                         

                    10/26/2005 11:44                                                                                   
                    AM                                                                                                 
                    Please respond to                                                                                  
                    Mailing List                                                                                       

Group,

           This is only assuming

           Mitchell Erblich
           ------------------

Acee Lindem wrote:
> >    1.Neighbors immediately send hello packet to peer when they receive
hello packet from the peer that first sent the hello packet.
> >    2.Based 1,routers( marked X) that sent the hello packet will repidly
receive their neighbors hello packet carrying their peers(X) information.
> >    3.After 2,DR will start to be electedŁŹbuilding the relation of
adjacency and completing link state database synchronization.

---

From: Erblichs <[email-masked]>
Date: Wed, 26 Oct 2005 12:54:45 -0700

Greg,

	You are assuming that all adj are equal. Some adj are
	more equal than others in respect to Mb/sec, QOS, etc.

	On these prioritized adjs, we can improve convergence.
	
	Scaling is not a requirement. Only that the faster
	convergence is better than doing the defacto standard
	and minimize the loss or mis-direction of data for these
	"unequal adjs".

	If you don't do it now, then why not?

	Mitchell Erblich
	-----------------

---

From: Acee Lindem <[email-masked]>
Date: Wed, 26 Oct 2005 16:16:48 -0400

>	If you don't do it now, then why not?
Actually this is the under the purview of the Routing Area WG (rtwg):

http://www.ietf.org/html.charters/rtgwg-charter.html

You may want to read their drafts and participate in the attendant 
discussion.

Acee

>>           Mitchell Erblich
>>           ------------------
>>
>>Acee Lindem wrote:
>>    
>>
>>>Hi Kou,
>>>
>>>kouzengjie wrote:
>>>
>>>      
>>>
>>>>All,
>>>>   OSPF convergence contains neighbor discovery and link state database
>>>>        
>>>>
>>synchronization.
>>    
>>
>>>>Neighbor discovery is achieved by hello protocol. Default hello interval
>>>>        
>>>>
>>is 10s.
>>    
>>
>>>>Hello packets sent by neighbors is not work on each other.So,covergence
>>>>        
>>>>
>>time is longer.
>>    
>>
>>>>If adopting following proposition,then covergence time  is decreased
>>>>        
>>>>
>>very much on broadcast networks.
>>    
>>
>>>>   4.After database synchronization,the hello packet will be sent every
>>>>        
>>>>
>>provious interval each other.
>>    
>>

---

From: Kouzengjie <[email-masked]>
Date: Thu, 27 Oct 2005 09:45:54 +0800

Hi Acee,
    Now,we are sure of  the fact that either neighbor state becoming "2-way" state is faster than prior by the mechanism.

Thanks,
Kou

---

From: Acee Lindem <[email-masked]>
Date: Thu, 27 Oct 2005 02:08:10 -0400

Hi Kou,

In some situations, unicasting a hello in response to a newly discovered
neighbor will get
you to 2-way faster. As I stated earlier, existing implementations use
this technique. What
is your point?

Thanks,
Acee

---

From: Kouzengjie <[email-masked]>
Date: Thu, 27 Oct 2005 15:13:45 +0800

Hi,Acee
    Yes,I see.
    
    I have an idea that I want to write a draft about this technique and promote it bocomes a standard extension of OSPF.
    How do you think it?

Thanks,
Kou

---

From: Acee Lindem <[email-masked]>
Date: Thu, 27 Oct 2005 19:48:33 -0400

Hi Kou,

In general, I don't think we should try and optimise standardized
mechanisms for specific scenarios without compelling requirements. If
you feel there is
a strong requirement you are certainly free to make a proposal and
attempt to
garner support.

Thanks,
Acee