Re: Restart signaling, DR/BDR, and RouterDeadInterval

["Manral, Vishwas" <[e-mail]>]

Folks,

I had further thoughts, on this("restart signaling") and "hitless restart"
in general.

1. I guess in case of "restart signalling" it could help to actually
maintain DR state. This could be easily done by checking DR value from
neighbors hellos on broadcast/nbma interfaces and using that value in the
hellos, before sending own hellos.

2. I have been wondering about this for some time.

If a router could make out that the other end is hitless restart capable and
is going an unplanned restart, we could wait for some more
time(HitlessRestartInterval > RouterDeadInterval) that could be signalled
whenever the adjacencies were brought up at init time. The way to do this
could be to check if pings are working, to the neighbors interface, but the
OSPF process itself is not working.

What I mean to say if the helper could be informed that the adjacent router
is going an unplanned outage(by any method) it could actually wait for a
longer period than the RouterDeadInterval in case of unplanned outage too.
So couldn't we keep a provision for this.

3. Regarding the avoiding exit of hitless restart in case we know that
routing loops would not occur. The conclusion I got to was that
   a) We could either have a helper H, exit hitless restart whenever a route
to D in the helper H changed (as agreed before earlier on the list). (i.e.
the route on atleast one of the neighbors would change for a route on the
restarting router R to change)
   b) Or we could have if a changed PATH on helper H to the destination D,
does not go thru the restarting router R, we need not exit hitless restart.

However we need would require all routers H to have the same behaviour(a or
b). My observation to the above is that, it would be easier to do a).

Thanks,
Vishwas

-----Original Message-----
From: Manral, Vishwas [mailto:[e-mail]]
Sent: Friday, May 10, 2002 11:13 PM
To: [e-mail]
Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval


Mitchell,

I guess the "restart signaling" draft is now located at
http://www.ietf.org/internet-drafts/draft-nguyen-ospf-restart-00.txt

Though Alex, or some other draft author would give the exact details, I
think this draft does not bother about keeping DR state, so if a DR router
goes down, and comes up it may no longer be the DR after the DR election.
Things I guess work as per the base RFC2328.

Acee,

Thanks for the information. (However I don't remember asking a question
related to this. ;-))

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:[e-mail]]
Sent: Friday, May 10, 2002 9:07 PM
To: [e-mail]
Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval


Michelle, Manral,

There are two hitless restart drafts. Although I was not at
the specific meeting, the one below is the one that was accepted
by the OSPF work group.

http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt

IMHO, it does address your questions although there is
currently no provision for a restart that doesn't proceed within
the router dead interval. We are considering this for our
implementation.


Erblichs wrote:
> OSPF Restart Signaling.. Feb01 to Sept01
>
> Hi Group,
>
>         I didn't see if this became a standard, so
>         this clarification / question could be moot..
>
>         Just thinking of the proper way to code
>         this..
>
>         I assume that if a hello is recieved from
>         a restart router within the RouterDeadInterval
>         timeframe, then there is significantly less
>         work... There was no intervening teardown..
>
>         However, what is not mentioned, and I want to
>         clarify this..
>
>         Assume both routers support Restart..
>         If the restarting router was the DR or the BDR,
>         there is no assumption that if the restart was
>         done WITHIN the RouterDeadInterval timeframe,
>         the adjacency is still up, that a restarting
>         router would stay the BDR or DR...
>
>         Assume both routers support restart..
>         Else, NOT WITHIN the RouterDeadInterval timeframe.
>         We have to assume that there was a intervening
>         election. Would we do another election?
>
>         There is no mention of election effects / side-effects
>         with respect to the restarting router, when all or
>         some routers support restart? The non-restart supported
>         routers would force a re-election.
>
>         Thanks,
>                 Mitchell Erblich
>


--
Acee