[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-kou-ospf-immediately-replying-hello-00.txt



Zengjie Kou wrote:

Hi, Acee
On p2p networks, there is no distinction between first coming or coming back up. The immediate hello is efficient in discover neighbors and convergence.
On broadcast networks, when an interface first coming, DR election need to wait wait-time. However, when an interface coming back up, DR election need not to wait wait-time(if BDR exists or the down interface is not DR). Here, only HelloInterval or BackupSeen is needed to discover neighbor or convergence. Immediate hello avoids the HelloInterval or backupSeen on the case.


Hi Zengjie,

I think you're saying the hello when the DR/BDR interface state changes is solely for
the case when the BDR's interface flaps. Correct?


BDR Interface goes down
Ex-BDR Interface comes back up
Ex-BDR send initial hello ----------------------------> Other Routers on LAN
Ex-BDR goes to 2-way <---------------------------- Other Routers Immediate reply
New DR/BDR election
Triggers election on Ex-BDR <---------------------- New DR/BDR send hello


Why not just process the neighbor change event before sending the immediate reply?
In other words, perform the new DR/BDR election before the immediate reply hello?
Thanks,
Acee


Thanks,
Zengjie


----- Original Message ----- From: "Acee Lindem" <acee at CISCO.COM>
To: <OSPF at PEACH.EASE.LSOFT.COM>
Sent: Friday, February 24, 2006 10:10 PM
Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt





Zengjie Kou wrote:



Hi, Acee
The empty hello mechanism that you refered is adopted by most OSPF implementations indeed when an interface first comes up.
I agree this. However, when an normal interface whose state is up goes down then up, immediate hello is effective by avoiding helloInterval or backupSeen.





Hi Zengjie,

I don't think there should be a distinction between first coming or coming back up.

Thanks,
Acee



Thanks,
Zengjie

----- Original Message ----- From: "Acee Lindem" <acee at CISCO.COM>
To: <OSPF at PEACH.EASE.LSOFT.COM>
Sent: Thursday, February 23, 2006 5:41 AM
Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt







Zengjie Kou wrote:





Hi, Acee,
 You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed.






Hi Zengjie,

Speaking strictly in terms of state machines, it seems the interface would lose it's DR/BDR state
when it goes down (and cannot send a hello). Wouldn't this scenario be better handled
by the empty hello many OSPF implementations send when an interface first comes up?


Thanks,
Acee





Thanks,
Zengjie

----- Original Message ----- From: "Acee Lindem" <acee at CISCO.COM>
To: <OSPF at PEACH.EASE.LSOFT.COM>
Sent: Monday, February 20, 2006 11:15 PM
Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt









Hi Zengjie,

Zengjie Kou wrote:







Hi,Acee,
If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello.








This is only when the DR/BDR knows that it is going down or the case where the router
priority is set to 0.


For a router becoming DR/BDR, all the routers should elect the same DR/BDR
so I don't see how it helps.

Thanks,
Acee







After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen.
Namely, improving convergence.

Thanks a lot,
Zengjie

----- Original Message ----- From: "Acee Lindem" <acee at CISCO.COM>
To: <OSPF at PEACH.EASE.LSOFT.COM>
Sent: Saturday, February 18, 2006 5:17 AM
Subject: draft-kou-ospf-immediately-replying-hello-00.txt











Hi Zengjie,

Under what situations does having the router who changed to/from
DR/BDR improve convergence (section 6.2)? Since DR/BDR election
is a distributed algorithm dependent on the calculating routers state, it
seems this won't help in all that many cases.

Thanks,
Acee