|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Harikrishna G. (harikrishnag
NETPLANE.COM)Date: Mon Mar 04 2002 - 05:51:33 CST
Hi All,
disregard my ealrier mail. I wanted to send that to Rohit alone but
ended
up sending it to all :-)
Rgds,
Hari
-----Original Message-----
From: Rohit Dube [mailto:rohit
XEBEO.COM]
Sent: Saturday, March 02, 2002 12:19 AM
To: OSPF
DISCUSS.MICROSOFT.COM
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
Best,
--rohit.
On Fri, 1 Mar 2002 12:41:59 -0500 "Manral, Vishwas" writes:
=>John,
=>
=>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
Aman
=>Shaikh(and a few other at Research at AT&T), I have come up with the
=>following proof.
=>
=>>From the previous thread ===>>
=>======================================================================
=>Vishwas>
=>> 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
helper's
=>routing table may not change, but a larger loop may have formed. It
*would*
=>be OK to see whether the *restarting router's* routing table has changed,
=>but
=>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
on
=>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),
if
=>restarting router is not the ABR).
=>
=>To explain it :-
=>=============
=>
=>If we assume that nothing incident on R changed, then I dont think u can
=>find a
=>case where R's path to D changes but none of the helper's path to D
changes.
=>At
=>least one helper will see a change in path cost if nothing else. I think
=>this
=>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
=>helper"
=>in R's SPT. In that case, that helper should see some change in its path
to
=>D as
=>well.
=>
=>Here's an example where R's path to D changes, none its ngb's path to D
=>changes.
=>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)
=>R<->A (1)
=>R<->B (1)
=>A<->A' (5)
=>B<->B' (4)
=>A'<->D (1)
=>B'<->D (1)
=>
=>Then every router's path to D would look like this:
=>
=>R->B->B'->D (6)
=>A->A'->D (6)
=>B->B'->D (5)
=>A'->D (1)
=>B'->D (1)
=>
=>Suppose cost of B<->B' changes to 6 from 4.
=>
=>Then every router's path to D would be like this:
=>
=>R->A->A'->D (7)
=>A->A'->D (6)
=>B->B'->D (7) <= Change in path cost.
=>A'->D (1)
=>B'->D (1)
=>
=>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,
or
=>a route in the helper changes(both the above amount to this too).
=>
=>Please correct me if I am wrong.
=>
=>Thanks,
=>Vishwas
___
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]