OSEC

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. (harikrishnagNETPLANE.COM)
Date: Mon Mar 04 2002 - 05:51:33 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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:rohitXEBEO.COM]
    Sent: Saturday, March 02, 2002 12:19 AM
    To: OSPFDISCUSS.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
    ___