Subject: Waiting State Question

From: John Smith <[email-masked]>
Date: Thu, 19 May 2005 13:20:20 +0100

Hi,

When a router comes up it starts the Wait Timer before it elects the DR/BDR. It either
waits for the Wait Timer to expire or it waits for a router declaring itself as the BDR
before it decides that it needs to get out of the 'Waiting' state (it does this by
generating the Backupseen event). 

My question is why does it wait only for the BDR? Why not the DR? It can when it recieves
a HELLO from the DR know that their exists a DR and a BDR. Why not then get out of the
'Waiting' state?

Thanks,
John

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: Anthony Baire <[email-masked]>
Date: Thu, 19 May 2005 16:32:52 +0200

> a HELLO from the DR know that their exists a DR and a BDR. Why not then

Hi John,

this is not the exact definition of event BackupSeen. The event is
generated when the router detects the existence or non-existence of a
backup designated router. This can be done by receiving a Hello packet
from a DR claiming that there is no BDR on the network.

Anthony

---

From: Kishore Rao <[email-masked]>
Date: Thu, 19 May 2005 10:55:02 -0600

> a HELLO from the DR know that their exists a DR and a BDR. Why not then
get out of the

It also waits for a router to declare itself as a DR (section 10.5 Receving
Hello packets). The
'Neighborchange' event triggers DR election.

[Otherwise, if the neighbor is declaring itself to be Designated Router and
it had not previously,
or the neighbor is not declaring itself  Designated Router where it had
previously, the receiving
interface's state machine is scheduled with the event NeighborChange.]

Kishore

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 19 May 2005 13:14:22 -0500

My guess is that if an interface comes out of the waiting state on receiving a
Hello from DR (without having received a Hello from BDR), it may elect itself
as BDR. This way many routers may elect themselves as BDR. Now all these BDR
claimants (except one) will ultimately take their claims to BDRship back but in
the process each router on the LAN may have to do several DR elections.

Here is a paper we wrote recently that may shed further light on this:
http://cs.uwm.edu/~mukul/ospflan.pdf

Thanks,
Mukul

---

From: Erblichs <[email-masked]>
Date: Thu, 19 May 2005 11:31:31 -0700

Anthony, et al,

	I am not sure what you are stating is correct.

	When an interface becomes active, the router checks
	the hellos on that interface for a period of
	time, known as the Waiting period in environments
	that supports DR and BDRs.

	If the interface is a passive interface, then ...
	Else {

	If one DR is seen and we are not declaring ourselves
	as the DR, we accept it and synch our LSDB, etc...

	}

	Else...

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

---

From: Kishore Rao <[email-masked]>
Date: Thu, 19 May 2005 12:44:36 -0600

The question was not about how DR or BDRs are elected. John's question was
if the router should exit Wait Timer (and run DR election) on receving Hello
from a router declaring itself as DR. Well, from section 10.5 it should.

Kishore

> > When a router comes up it starts the Wait Timer before it elects the
DR/BDR.
> > It either
> > waits for the Wait Timer to expire or it waits for a router declaring
itself
> > as the BDR
> > before it decides that it needs to get out of the 'Waiting' state (it
does
> > this by
> > My question is why does it wait only for the BDR? Why not the DR? It can
when
> > it recieves
> > a HELLO from the DR know that their exists a DR and a BDR. Why not then
get
> > out of the

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 19 May 2005 13:53:41 -0500

I think the NeighborChange events are ignored while an interface is in waiting
state.

Thanks,
Mukul

---

From: Kishore Rao <[email-masked]>
Date: Thu, 19 May 2005 13:08:32 -0600

Not NeighborChange but Backupseen

"If the neighbor is both declaring itself to be Designated
            Router (Hello Packet's Designated Router field = Neighbor IP
            address) and the Backup Designated Router field in the
            packet is equal to 0.0.0.0 and the receiving interface is in
            state Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen."

> > > as BDR. This way many routers may elect themselves as BDR. Now all
these
> > BDR
> > > claimants (except one) will ultimately take their claims to BDRship
back
> > but in

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 19 May 2005 14:28:31 -0500

OK. So we agree that an interface comes out of waiting state on receiving a
Hello from DR IF that hello does not list any BDR. OTHERWISE an interface does
not come out of waiting state on receiving a Hello from DR.

---

From: Kishore Rao <[email-masked]>
Date: Thu, 19 May 2005 13:32:40 -0600

Right.

> > > > The question was not about how DR or BDRs are elected. John's
question
> > was
> > > > if the router should exit Wait Timer (and run DR election) on
receving
> > Hello
> > > > > Hello from DR (without having received a Hello from BDR), it may
elect
> > > > > > before it decides that it needs to get out of the 'Waiting'
state
> > (it
> > > > > > My question is why does it wait only for the BDR? Why not the
DR? It
> > can
> > > > when
> > > > > > it recieves
> > > > > > a HELLO from the DR know that their exists a DR and a BDR. Why
not
> > then

---

From: Erblichs <[email-masked]>
Date: Thu, 19 May 2005 12:51:50 -0700

Sorry,

	I have to kind of disagree on two accounts with the
	spec vs implimentations..

	First, if the interface is a passive interface. I
	think passives interfaces are after the spec, thus
	it fits as an exception. But in my opinion, passive
	interfaces have a equiv as a infinite waiting
	period.

	Second, "in the case where more than 1 router"
	is declaring itself as the DR, shouldn't enough 
	time pass (1.5 to 2x) hello interval pass to identify
	this situation before exiting wait state and
	poss determine whether 2-ways are forming.  Yes,
	it could/should exit early, but on that first 
	hello???

	Thus, this section of the spec covers the rare simple 
	case where no BDR has yet been elected or is eligible
	to be elected.

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

---

From: Kishore Rao <[email-masked]>
Date: Thu, 19 May 2005 15:25:44 -0600

> it could/should exit early, but on that first

A possible case of A & B declaring themselves as DR would be when comm. b/n
them is broken; in which case shouldn't router C prefer to elect itself as
BDR ASAP on receiving the hello from either A or B instead of waiting for a
longer period of time without the possiblity of neither A or B being elected
BDR during that time ?

question
receving
elect
state
DR? It
not

---

From: Erblichs <[email-masked]>
Date: Thu, 19 May 2005 19:45:53 -0700

What is b/n them is broken?

Combine areas and former entry/exit interfaces between
the areas will result in two or more DRs announcements
per pseudonode.

This is taken care of in the Spec? Can anyone find the
section? :-)

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

---

From: Kishore Rao <[email-masked]>
Date: Fri, 20 May 2005 11:10:28 -0600

> What is b/n them is broken?

Comunication between them is broken.

> This is taken care of in the Spec? Can anyone find the

Section F: Multiple interfaces to the same network/subnet.

I could not find any other section other than this.

F:  says both the interface should be taken care of together so that there
are no
multiple DRs elected by the same router. In your case, DRs were elected by
two different routers,
which I think could happen only if they have no communication beween them ?

Kishore

> > > > > I think the NeighborChange events are ignored while an interface
is in
> > > > waiting
> > > > > > > My guess is that if an interface comes out of the waiting
state on
> > > > > > receiving a
> > > > > > > Here is a paper we wrote recently that may shed further light
on
> > this:
> > > > > > > > When a router comes up it starts the Wait Timer before it
elects
> > the

---

From: Erblichs <[email-masked]>
Date: Wed, 25 May 2005 01:52:41 -0700

Kishore Rao,

	Sorry for the late response.
	Lets see. Oh...

	Adj communciation causing a split area can
	be done intentionally and un-intentionally...
	
	One might intentionally impliment a dual or more
	routing paths thru an area because..

	  One wishes to support the equiv of a VPN where
	  each group uses a diff MD5 auth.

	  OSPF does not offically support unequal cost
	  paths and thus alternate routes would be
	  unused without MPLS.

	  We wish to minimize the number of routers
	  within a grouping.

	  we wish to minimize the number of LSAs per
	  group.

	  We wish to only inject routes from other
	  routing protcols into one group.

	  We wish to support a different set of routers
	  per ISP and maybe have a limited number of
	  merge points.

	  We wish to support a subset of routers for
	  only transit traffic..

	  We wish to support a very fast hello interval
	  for one group and that functionally or someother
	  functionally is ONLY supported by a subset of
	  the routers..

	  etc...

	And unintentionally because one or more adj early
	  adj formation parameters, (hello fields) are diff,
	  thus dropping the hello pkt..

	  Because a full adj is unstable and past history
	  is delaying our newest adj formation.

	  Or,,, because we are in the latency time period
	  before we identify that we have two DRs..

	OR, because the new router / DR on that interface
	has a higher capability and we would rather have
	a re-election of DR, versus taking down all the
	routers for dead router interval..

	OR  ... 

	But it is too simple to declare "because the
	adj is broken".. It is because their are MANY
	reasons.

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

---

From: sujay <[email-masked]>
Date: Wed, 25 May 2005 19:55:33 +0530

Hi All,

Considering RFC3623, Graceful Restart for OSPF V2 I have a problem;

Ex:

  (network)---- DUT ---- RTA

(All in the same area)

Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's to
RTA and other routers in the 'network'

At the instant RTA recvs the Grace-LSA it also goes down.

Is there a way in the RFC 3623 specified as to how DUT could 
Detect this topology change and Exit GR *before* grace period expiry??

For other routers in the network RTA is still reachable and traffic 
Will be eventually dropped.

Kindly correct me,

Regds,
Ashok/Sujay

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 25 May 2005 08:02:42 -0700

>Detect this topology change and Exit GR *before* grace period expiry??
I do not think the RFC covers this case. You are in a double failure 
situation.

I can think of a simple solution. When DUT reacquires its router-lsa. It 
can determine its previous
neighbors. It can then decide that if within DeadRouterInterval that 
neighbor did not  respond
to hellos to abort GR. This would be equivalent to the normal situation 
when a router goes down and its
neigbors takes DeadInterval to bring down their adjacency

Padma.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 25 May 2005 12:10:38 -0400

Padma Pillay-Esnault wrote:

>> Is there a way in the RFC 3623 specified as to how DUT could Detect 
>> this topology change and Exit GR *before* grace period expiry??
>>  
>>
> I can think of a simple solution. When DUT reacquires its router-lsa. 
> It can determine its previous
> to hellos to abort GR. This would be equivalent to the normal 
> situation when a router goes down and its

I agree completely with Padma. One point, if RTA comes back up and 
originates a new router LSA
then the DUT will detect the inconsistency (as specified in RFC 3623) 
with it's pre-restart LSA and
terminate graceful restart.

---

From: Kishore Rao <[email-masked]>
Date: Wed, 25 May 2005 11:50:39 -0600

----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 25, 2005 10:10 AM
Subject: Re: Exit-Graceful Restart Condition

> terminate graceful restart.

Acee,

Will this work ?
In case there is another router RTB, scan the Hello from RTB for all
neighbors on the network and then make sure Hello from RTA has been received
within a Hello interval + 2 (say) . If not, exit GR.

This would be faster than using the reacquired Router and Network LSAs to
determine the neighbors, isnt it ?

Kishore

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 25 May 2005 10:54:20 -0700

>within a Hello interval + 2 (say) . If not, exit GR.
It is not clear to me. Do you mean that RTB has the same neighbors as 
DUT and is on the same network link ?

Padma

---

From: ashok holla <[email-masked]>
Date: Wed, 25 May 2005 23:51:55 +0530

Hi,
When myself and Sujay raised this issue, we thought about the
possibility which Pama and Acee suggested.
However, this will not work in all cases.

Consider:

TOPO------------------------ DUT---------------------------RTA
          Area0                                Area1
In this case, DUT will not get his pre-restart router of Area 1 as
there no other router in the area to give it to him.
Therefore, this solution fails. 
In this case, suppose DUT had run the spf, he would have seen that the
type-3 summary lsa he had advertised into area 0, is no longer
consistent with the topology and then could have exited GR. However,
this consistensy check can be done only after grace period terminates
as RTA MAY come up within that time.
So, for this case, there seems to be no solution.

However, it does seem to be worthwhile to start deadTimers for all
nbrs listed in the pre-restart router lsa when we get it for the first
time.  (even though we have not received hello pkts from them). When
any inactivity timer fires on the restarting router, he can quit GR.
This can be done to impro convergence incase, topology is unstable.

Is our understanding correct?

regards,
Ashok/Sujay

-- 
Best regards,
Ashok Chandrashekar Holla

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 25 May 2005 11:46:40 -0700

>So, for this case, there seems to be no solution.
You have not taken into account one major premise in thr rfc -
For graceful restart to success you MUST have a helper to enable you to 
recover.
In the case above you have
1. A double failure
2. No helper in the area

With 2 - There can be no GR restart in the first place. Optimizing the 
detection is not possible if you do not even
 have the list of your previous neighbors.

>This can be done to impro convergence incase, topology is unstable.
I would put that as an option rather than a "must".

Padma

---

From: Kishore Rao <[email-masked]>
Date: Wed, 25 May 2005 12:54:25 -0600

----- Original Message ----- 
From: "Padma Pillay-Esnault" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 25, 2005 11:54 AM
Subject: Re: Exit-Graceful Restart Condition

> DUT and is on the same network link ?

Yes.

---

From: Kishore Rao <[email-masked]>
Date: Wed, 25 May 2005 13:03:45 -0600

----- Original Message ----- 
From: "Padma Pillay-Esnault" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 25, 2005 12:46 PM
Subject: Re: Exit-Graceful Restart Condition

>  have the list of your previous neighbors.

If no neighbors are detected after the interface Hello interval, wouldn't
exiting GR be advisable instead of waiting for grace timer to expire ?

Kishore

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 27 May 2005 08:09:57 -0700

Kishore Rao wrote:

>>>neighbors on the network and then make sure Hello from RTA has been
>>>      
>>>
>received
>  
>

This is not a solution that you can rely one. For one - you can only use 
it on a BCAST interface where there are
2+ neighbors possible. It will not work for p2p for example.

I prefer a generic solution.

Padma

---

From: sujay <[email-masked]>
Date: Mon, 30 May 2005 09:43:55 +0530

Hi Padma,

Guess we *must* run the dead interval timer on a per neighbor basis,
else
 for the maximum configured dead interval amongst all possible
neighbours.
It could be of course implementation specific.

Solves more than the one issue mentioned in this thread !

Regds,
Sujay

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Friday, May 27, 2005 8:40 PM
To: [email-masked]
Subject: Re: Exit-Graceful Restart Condition

Kishore Rao wrote:

>>>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's 
>>>>>>to RTA and other routers in the 'network'
>>>>>>
>>>>>I do not think the RFC covers this case. You are in a double 
>>>>>failure situation.
>>>>>
>>>>>I can think of a simple solution. When DUT reacquires its 
>>>>>router-lsa. It can determine its previous neighbors. It can then 
>>>>>decide that if within DeadRouterInterval that neighbor did not  
>>>>>respond to hellos to abort GR. This would be equivalent to the 
>>>>>normal situation when a router goes down and its
>>>>originates a new router LSA then the DUT will detect the 
>>>>inconsistency (as specified in RFC 3623) with it's pre-restart LSA 
>>>>and terminate graceful restart.
>>>>
>>>>
>>>>        
>>>>
>>>Acee,
>>>
>>>Will this work ?

Padma

>
>  
>
>>Padma
>>
>>    
>>
>>>This would be faster than using the reacquired Router and Network 
>>>LSAs to determine the neighbors, isnt it ?
>>>
>>>Kishore
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>        
>>>>
>>>>>Padma.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>For other routers in the network RTA is still reachable and 
>>>>>>traffic Will be eventually dropped.
>>>>>>
>>>>>>Kindly correct me,
>>>>>>
>>>>>>Regds,
>>>>>>Ashok/Sujay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>
>>>      
>>>
>
>  
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 31 May 2005 18:28:46 -0400

>Guess we *must* run the dead interval timer on a per neighbor basis,
Hi Sujay,

IMHO, this is the norm rather than the exception.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 31 May 2005 15:40:04 -0700

> IMHO, this is the norm rather than the exception.

Agree - this is usual behavior.

Padma

>>>>>>>> Assume DUT undergoes a Graceful-Restart, it sends out grace 
>>>>>>>> LSA's to RTA and other routers in the 'network'
>>>>>>>>
>>>>>> I agree completely with Padma. One point, if RTA comes back up 
>>>>>> and originates a new router LSA then the DUT will detect the 
>>>>>> inconsistency (as specified in RFC 3623) with it's pre-restart 
>>>>>> LSA and terminate graceful restart.
>>>>>>
>>>>>>
>>>>>>      
>>>>>>         
>>>>>
>>>>> Acee,
>>>>>
>>>>> Will this work ?
>>>>> In case there is another router RTB, scan the Hello from RTB for 
>>>>> all neighbors on the network and then make sure Hello from RTA has 
>>>>> been
>>>>>    
>>>>>       
>>>>
>>> received
>>>
>>>
>>>   
>>>
>>>> It is not clear to me. Do you mean that RTB has the same neighbors 
>>>> as DUT and is on the same network link ?
>>>>  
>>>>     
>>>
>>> Yes.
>>>
>>>
>>>   
>>
>>