Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Harikrishna G. (harikrishnagNETPLANE.COM)
Date: Mon Mar 04 2002 - 05:51:33 CST
disregard my ealrier mail. I wanted to send that to Rohit alone but
up sending it to all :-)
From: Rohit Dube [mailto:rohitXEBEO.COM]
Sent: Saturday, March 02, 2002 12:19 AM
Subject: Re: Explained: Regarding draft-ietf-ospf-hitless-restart-01.txt
Since this thread was restarted, I figured folks interested in the
topic may want to take a peek at the paper,
"Avoiding Instability during Graceful Shutdown of OSPF". A copy
can be found at http://members.tripod.com/~rohit_dube/publications.html
On Fri, 1 Mar 2002 12:41:59 -0500 "Manral, Vishwas" writes:
=>I know, I am replying to a thread that is about 4 months old(a new version
=>of draft is out, however the issue still holds). But this thing has been
=>nagging me for some while and after pursuing thingsand with the help of
=>Shaikh(and a few other at Research at AT&T), I have come up with the
=>>From the previous thread ===>>
=>> 6. We talk abt no changes to the contents of the LS
=>> Database(1-5, 7) for a
=>> router to get out of "helper mode" . Why dont we instead have
=>> a check some
=>> thing like a change in the routing table, with the particular
=>> router as the
=>> next hop. In the sense, if any router in helper mode has its
=>> routes changed,
=>> should we get out of "helper mode". Only when the path
=>> traverses thru the
=>> "restarting router" changes, do we need to actually update the path.
=>John> I don't think that this is good enough to stop all loops. The
=>routing table may not change, but a larger loop may have formed. It
=>be OK to see whether the *restarting router's* routing table has changed,
=>that's asking the helper to do quite a lot of extra work.
=>To explain further, if we assume there is no change of cost/link-up/down
=>any of the helpers, then a change in route in the Helper R for any
=>destination D would cause a change in atleast one helper(assuming all
=>routers are in the same area(maybe we can extrapolate to non-ABR's too),
=>restarting router is not the ABR).
=>To explain it :-
=>If we assume that nothing incident on R changed, then I dont think u can
=>case where R's path to D changes but none of the helper's path to D
=>least one helper will see a change in path cost if nothing else. I think
=>can be proved if u consider that if R's path to D changes and none of its
=>incident links have changed, then something must have changed "below a
=>in R's SPT. In that case, that helper should see some change in its path
=>Here's an example where R's path to D changes, none its ngb's path to D
=>Nonetheless one ngb sees a change in the path length
=>Suppose graph is like this:
=>link (cost: assumed to be same in both the directions)
=>Then every router's path to D would look like this:
=>Suppose cost of B<->B' changes to 6 from 4.
=>Then every router's path to D would be like this:
=>B->B'->D (7) <= Change in path cost.
=>So, what I mean to say is, that we need not exit hitless restart unless
=>either a link on the helper either goes down/up or we change cost on it,
=>a route in the helper changes(both the above amount to this too).
=>Please correct me if I am wrong.