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

From: Kouzengjie <[email-masked]>
Date: Thu, 29 Dec 2005 10:21:10 +0800

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.

---

From: Nitin Kakkar <[email-masked]>
Date: Thu, 29 Dec 2005 16:34:53 +0530

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:[email-masked]] On Behalf Of
Kouzengjie
Sent: Thursday, December 29, 2005 7:51 AM
To: [email-masked]
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.

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 29 Dec 2005 11:27:42 +0000

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

>    reach the OSPF "ExStart" state and  expedite the routing table 

___________________________________________________________ 
NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/

---

From: Erblichs <[email-masked]>
Date: Thu, 29 Dec 2005 13:24:38 -0800

Group,

	If my opinion counts for anything..

	0) The text has a number of unusal chars.

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

	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.

	   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"?

	  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?

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

	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?

	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.

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

> Kouzengjie wrote:
>    ˇ°ExStartˇą state more quickly. Currently, the OSPF behavior
> requires
>    reach the OSPF ˇ°ExStartˇą state and  expedite the routing table
>    convergence.

---

From: Zengjie Kou <[email-masked]>
Date: Fri, 30 Dec 2005 10:20:52 +0800

Hi,Nitin
    
    Yes.
    
    On broadcast and NBMA networks, the Immediate Hello is very useful only when DR has already existed.In 
   particular, if a router interface attached to OSPF networks goes 
   down and then up, the recovery time will be much shorter than past. 

  ----- Original Message ----- 
  From: Nitin Kakkar 
  To: [email-masked] 
  Sent: Thursday, December 29, 2005 7:04 PM
  Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

  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

---

From: Zengjie Kou <[email-masked]>
Date: Fri, 30 Dec 2005 10:40:04 +0800

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.

---

From: Don Goodspeed <[email-masked]>
Date: Thu, 29 Dec 2005 19:20:12 -0800

Only if everyone of the attached network implement this mechanism,
otherwise how could it.

A shared hub or switch goes down then comes back up.  Two routers
implementing the mechanism have a lower priority than a 3rd router
that has a higher priority and had been the DR.  The two lower priority
routers "ack" each other and go to ExStart then Full and one of the
two is elected DR, churning the network LSAs.

Am I missing something here?

-don

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Zengjie Kou
Sent: Thursday, December 29, 2005 6:40 PM
To: Mailing List
Subject: Re: Update to OSPF Hello
procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

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.

---

From: Erblichs <[email-masked]>
Date: Thu, 29 Dec 2005 20:09:29 -0800

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.

	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

---

From: Nitin Kakkar <[email-masked]>
Date: Fri, 30 Dec 2005 11:28:57 +0530

Manav,
 That's the entire point routers with higher priority may not get chance to
participate in DR election. Now DR election depends on the order in which
routers come up and send hello. There is no grace time for other routers to
come up and announce themselves.

Nitin

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Manav
Bhatia
Sent: Thursday, December 29, 2005 4:58 PM
To: [email-masked]
Subject: Re: Update to OSPF Hello
procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

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

		
___________________________________________________________ 
NEW Yahoo! Cars - sell your car and browse thousands of new and used cars
online! http://uk.cars.yahoo.com/

---

From: Zengjie Kou <[email-masked]>
Date: Fri, 30 Dec 2005 15:17:57 +0800

Hi,Mitchell

    Please see inline for answers to your questions.

----- Original Message ----- 
From: "Erblichs" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 30, 2005 5:24 AM
Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

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

>    not sure of this benefit.. However..
    It economizes a HelloInterval.

>           hellos for 10 nbrs? Each nbr send out a reply
    Your calculation is fit when all router boot first. However,for interface up/dow, it it only 27 hellos.

>    What is "Fast hello" and "intention"?
    Fast hello: shorten HelloInterval.
    intention: reduce the time to reach the "ExStart".

>       validation and acceptance?
    The Immediate hello is performed after hello parameters match each other.

    Yes.

>    hellos can consume alot of bandwidth for routers
    when flaping, the immediate hello expediates the link recovery. a few additional hellos will be brought, but it SHOULD consume a lot of bandwidth.

> 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

---

From: Zengjie Kou <[email-masked]>
Date: Sat, 31 Dec 2005 16:29:00 +0800

Hi,Mitchell

----- Original Message ----- 
From: "Erblichs" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 30, 2005 12:09 PM
Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

>    each other and the standard hellos are spread along the
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.

> to sync the LSDBs with the wrong DR?
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.

---

From: Paul Jakma <[email-masked]>
Date: Sat, 31 Dec 2005 14:34:29 +0000

> come up and announce themselves.

You'll just get another DR/BDR election in that case.

> Nitin

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Never look a gift horse in the mouth.
 		-- Saint Jerome

---

From: Paul Jakma <[email-masked]>
Date: Sat, 31 Dec 2005 16:05:43 +0000

Hi,

> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt

GNU Zebra's (and hence Quagga's) ospfd has done something like this 
for a long time now (a subset at least, send hello immediately if 
neighbour state changes into state Init).

One thing, might it be an idea to specify that the Immediate Hello be 
/independent/ of the Hello-Interval timer? (ie dont set or reset the 
interface's Hello timer because of any Immediate Hello sent). 
Otherwise, there'll be strong tendency for the HelloInterval timers 
across routers to latch. Not sure how much this matters.

Also, it might be an idea to add some state (e.g. a delay factor, 
some arbitrary protocol constant, 100ms or somesuch) to prevent 
Immediate-Hello storms if, for whatever reason, neighbour states fail 
to progress pass ExStart and fall back to Init. Some types of links 
are quite sensitive to L2 congestion for example.

6.1.1. Is there a good reason why pre-2-Way Immediate-Hellos are to 
be sent unicast?

If you happen to process multiple neighbour state changes (e.g. 
because of the delay factor on a previous immediate hello, or because 
the implementation chooses to define 'immediate' as 'very small 
delay'), one Immediate-Hello to AllSPFRouters can take care of all of 
them - rather than having to send multiple unicast hellos to each 
neighbour.

I.e. it might be an idea to just drop the modifications proposed in 
6.1.1.

regards,
  Earth men are real men!