John,

I have further narrowed down the case where we need to exit hitless restart.
My new statement is :-

Only when the new nexthop is thru R(because of some new LSA) to a
destination D, do we actually break off from hitless restart.

Proof: If a path does not traverse thru R no loop can occur. This is from
the simple fact that in that case only the router R has an askew routing
table, so if the path does not traverse thru it, it will not result in a
routing loop.

I guess this considerably reduces the case where we need to exit hitless
restart on any LSA change.

Thanks,
Vishwas

-----Original Message-----
From: Moy, John [mailto:John.MoySYCAMORENET.COM]
Sent: Tuesday, March 05, 2002 11:33 PM
To: OSPFDISCUSS.MICROSOFT.COM
Subject: Re: Explained: Regarding draft-ietf-ospf-hitless-restart-01.txt

Vishwas-

I *think* that you are correct, although I wouldn't
call your message a proof.

John

> -----Original Message-----
> From: Manral, Vishwas [mailto:VishwasMNETPLANE.COM]
> Sent: Friday, March 01, 2002 12:42 PM
> To: OSPFDISCUSS.MICROSOFT.COM
> Subject: Re: Explained: Regarding
> draft-ietf-ospf-hitless-restart-01.txt
>
>
> 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 ]