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

[Zengjie Kou <[e-mail]>]

hi,Mitchell

----- Original Message ----- 
From: "Erblichs" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, January 03, 2006 6:47 AM
Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]


> Zengjie Kou, et al,
> 
> First,
> 
> The v2 spec sect 9.5.1 Sending hellos with NBMA
> networks "at other times it is sent as a response
> to a recieved Hello packet".
> 
> It later mentions times when it should/must send
> hellos, with my understanding to limit hellos. Yes,
> this is in a time where the media bytes/sec was
> more limited.
> 
> So, a hello response is not a new idea.
> 
> Second,
> 
> > Sorry, I don't know what is your question.
>> 1)Why is DR election  interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information.
>> 
>> Thanks
>> Kou.
> OSPF specifies that once a DR and/or a BDR is elected
> we don't override the election if a new router comes
> up with a higher priority.
> 
> This is done, by accepting the hello fields that
> specify a DR / BDR normally by the DR / BDR, so we
> stop the process of election.
> 
> The question is when it stops. I have seen some
> implimentations only stop the election when a router
> has stated it is the DR / BDR on its first hello.
> This may be almost 10 secs by default after the
> interface comes up. Others will accept the DR / BDR
> on a later hello. 
> 
> Thus, It is the later hello or a delayed 10 sec if
> no hellos are lost or 30+ secs if a hello was lost
> that will stop the DR / BDR election.
> 
> Worse case scenario...
> Lastly on a BMA environment, if we have a number of 9 routers
> (follows with immediate hello responses) that come up in a 
> sequence in a 9 secs timeframe and the 10th router is the DR 
> (with a standard 10 sec periodic hello) chiming in with a
> hello at 10 secs.
> 
> Oh, we can change secs to ms and the same number of hellos
> would be exchanged.
> 
> This is how I see it with unicast hellos.... The logic is
> on the initial intf up, that router sends out a hello, then
> every router on the intf responds. The router sees its on
> id on the responding hellos, but needs now to respond to the
> responders so they can see their own ids. This is a fast
> adj formation and assumes that each router is capable of
> becoming the DR and/or the BDR.
> 
> Time 0 : 1st router comes up: Sends out a hello ; 1 (h) hello
> 
>      1  : 2nd                     "     "    1st one responds
>      2nd needs to respond
> both are now 2-way : 
> 1prev + 3new = 4
> 
>      2  : 3rd                     "     "
> 1st responds
> 3rd responds to 1st
> 2nd responds
> 3rd responds to 2nd
> all three are now 2-way
> 4 prev + 5 new = 9
> 
> 
> 
>     3 : 4th                    "        "
> 1st responds 
> 4th responds to 1st
> 2nd responds
> 4th responds to 2nd
> 3rd responds
> 4th responds to 3rd
> 9 prev + 7 : 16 hellos
> 
> 
> 4   : 5th     16 prev + 9new = 25
> 5   : 6th 25 prev + 11 new : 36
> 6:  : 7th 36 prev + 13 new : 49
> 7   : 8th 49 prev + 15 new : 64
> 8   : 9th 64 prev + 17 new : 81 hellos
> 
> Now the 10th pkt comes from the already up DR and all previous
> 9 respond. 81 prev + 1 hello from DR + 9 immediate replies= 91 hellos
> 
> And even with this logic, I still am not updating each hello
> time period. Starting at time 2, when 3rd responded to 1st router
> it did not include the knowledge of router 2. Thus, in theory
> 3rd SHOULD send again a hello pkt back to 1st that includes the
> router 2 in its information. So, the number of hellos is worse
> with proper updates. And is fairly complex because it now needs
> a list of nbrs that needs hellos and which become out of sync
> and thus need to be resync'ed.
> 
> IMO, this is ALOT of hellos...
> 
Again to verify:
 1.) Immediate Hello can be enable or disable.
 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ).

At the moment of router booting, the Immediate Hello is not fit. So, we can disable it.

Thanks
Kou.


> Mitchell Erblich
> -----------------------
> 
> 
> 
> 
> Zengjie Kou wrote:
>> 
>> Hi,Mitchell
>> 
>>     Please see inline for answers to your questions.
>> 
>> ----- Original Message -----
>> From: "Erblichs" <[e-mail]>
>> To: <[e-mail]>
>> Sent: Friday, December 30, 2005 12:09 PM
>> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]
>> 
>> > Kou,
>> >
>> > 1) A few extra hellos? You will force a matrix number
>> >    of hellos? With 10 routers, you will need 90 hellos.
>> >    With 100 routers, we have 9900 hellos I think, if
>> >    we need to respond to each nbr's hello. Where we have
>> >    2x the number of router's hellos in the standard method
>> >    with MC hellos (20 and 200). Oh, yours are with ms of
>> >    each other and the standard hellos are spread along the
>> >    hello interval.
>> >
>> 1.) Immediate Hello can be enable or disable.
>> 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ).
>> 
>> At the moment of router booting, the Immediate Hello is not fit. So, we can disable it.
>> 
>> > 2)
>> > I disagree, this can effect DR election.
>> >
>> > How? Assume their is a disagreement as to whom
>> > should be elected DR in the normal method. Now, with
>> > that quick hello, the faster router tells the other
>> > routers not just whom he choose, but who is the DR.
>> >
>> > Anytime before DR is elected, Y informs that X is the DR,
>> > then OSPF says X is the DR. You are saving on avg
>> > 1/2 hello interval time.
>> >
>> > Now, why can their be a disagreement? Simply, a late
>> > hello informing about a new router with a higher priority
>> > before the DR is elected.
>> >
>> > With the current method, we give an extra few secs, just
>> > to allow everyone to make up their own private decision, then
>> > publicise the decision, and if their is a disagreement after
>> > recieving the multiple public hellos, then resolve it.
>> >
>> > Yes, some implimentations ignore hellos with DR announcement
>> > after election has begun. But some don't. And I am refering
>> > to the later ones.
>> >
>> > Now, it gets complicated. Assume that 2 routers who accept
>> > the fast hello and the interruption of the DR process. Won't
>> > they form a full ADJ if one or both are the DR / BDR? Now,
>> > the 3rd guy heard a hello from the highest priority router
>> > and accepted him as the DR? Aren't you needlessly trying
>> > to sync the LSDBs with the wrong DR?
>> >
>> > Mitchell Erblich
>> >
>> >
>> >
>> Sorry, I don't know what is your question.
>> 1)Why is DR election  interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information.
>> 
>> Thanks
>> Kou.
>> 
>> > Zengjie Kou wrote:
>> >>
>> >> Hi,Manav
>> >>     I don't find any harm except a few additional hello packets before the state reaches "ExStart".
>> >>
>> >>     The Immediate Hello do not affect which router will be elected DR. It only expedite the election.
>> >>
>> >> thanks
>> >> kou.
>> >>
>> >> ----- Original Message -----
>> >> From: "Manav Bhatia" <[e-mail]>
>> >> To: <[e-mail]>
>> >> Sent: Thursday, December 29, 2005 7:27 PM
>> >> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]
>> >>
>> >> > So whats the harm in this?
>> >> >
>> >> > If you wanted a particular router to become the DR then you would have given it a higher priority.
>> >> > The fact that you havent done that implies that you dont really care which router becomes the DR.
>> >> >
>> >> > Manav
>> >> > --- Nitin Kakkar <[e-mail]> wrote:
>> >> >
>> >> >> Suppose there are n routers on a Link and all of them come up almost
>> >> >> simultaneously.
>> >> >>
>> >> >> Seems like the routers which were fractionally faster to send hello will be
>> >> >> picked for DR/BDR election !!!
>> >> >>
>> >> >>
>> >> >>
>> >> >> May be you can think of  immediately replying to hello packet "Only when DR
>> >> >> is already elected on the link".
>> >> >>
>> >> >>
>> >> >>
>> >> >> Rgds
>> >> >>
>> >> >> Nitin
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Mailing List [mailto:[e-mail]] On Behalf Of
>> >> >> Kouzengjie
>> >> >> Sent: Thursday, December 29, 2005 7:51 AM
>> >> >> To: [e-mail]
>> >> >> Subject: Update to OSPF Hello
>> >> >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt]
>> >> >>
>> >> >>
>> >> >>
>> >> >> 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-hell
>> >> >> o-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.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ___________________________________________________________
>> >> > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/