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

[Erblichs <[e-mail]>]

Zengie Kou,

	Sorry, I am still confused.

	Below I gave you a scenario of a seq of generating
	in excess of 81 hellos when the initial hello that
	is sent out is a MC hello and replies are then UC.
	Thus,. I don't see how you do 27 hellos unless you
	are filtering replies based on "c" below or such. My
	example below did no filtering because it is in a bringup
	environment and is trying to expedite "full adj" formations
	based on your draft-rfc..

	The MC hello is done when the link comes up and is
	currently extemely common with OSPF implimentations
	to expedite link formations. This I like.

	"recovery when a link goes down then up"
	I am assuming that link status is determined by xmit/recv
	of hellos in the below items..

	a) If the this happens within the dead router timeframe,
	how does one determine that the link is at fault vs
	dropped hellos at the recv'r or non xmit'ed pkts or ????
	Should we even care about replying in this ex?

	b) If this time frame occurs longer than the dead router
	   time frame, won't 99+% of implimentations remove the
	   now dead nbr? This is done mainly to shorten
	   the nbr lookup? How would you know if the router was
	   up in the first place  without history? How long should
	   you keep history? If history is kept, you would first
	   need to check current nbrs and if not their, then check
	   history and if their, promote that router. Isn't this alot
	   of extra overhead just because a link went down?

	c) If this is in a BMA envir, and the hello is from/to
	   DR-others (DR and BDR exist) OR it is not announcing itself 
	   as the (DR or BDR) should we even process the hello and form
	   a bad false-link to a nbr that can't go full? Thus these hellos
	   should be who cares!!! A who care hello SHOULD not be replied
	   to, IMO!!!!

	d) etc...

	Oh, and DR/BDR re-election can be done by having a router just
	announce itself as a DR/BDR within a hello. This is supported by
	area merging.

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

	

	

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 ).

Zengjie Kou wrote:
> 
> 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/