[email protected]
[Top] [All Lists]

Re: Type-C & FRR repair

Subject: Re: Type-C & FRR repair
From: Alia Atlas
Date: Fri, 03 Jun 2005 23:24:02 -0400

At 07:57 PM 6/3/2005, Alex Zinin wrote:
>> > In Sec 3.3, it seems to me that if there isn't an IPFRR alternate, then it >> > is possible for traffic to be dropped for DELAY_TYPEC. This would be the
>> > case where S's new primary next-hop is a type C itself.  I'm not sure if
>> > there's any way around this - but it may be worth thinking about a bit.
>>Indeed, I meant to ask for opinions on this. I had to put something in the
>>text, so I made a decision ;) I'll send a separate e-mail on this.

> The joy of writing it :-)
> My only opinion right now is that it'd be nice to find something better
> ;-)  I'll think about it some more.

My logic was: there seems to be two options:

 1) switch to the new next-hop immediately and risk having loops OR
 2) keep the old next-hops and black-hole the traffic until it's safe

and unless a loop is so micro it may recover before BW is severely affected
or TTL gets down to 0, I generally prefer to black-hole, hence the
Absolutely agree. I can't think of any other possibilities. If S doesn't
have either a loop-free alternate or a safe neighbor, then, without an
advanced method, S can't safely send to any neighbor until that neighbor
has converged - which means I don't think there are any other options.
> Is it interesting to distinguish between the case where a router doesn't
> support IPFRR and the case where the router supports IPFRR but doesn't have
> an alternate for the particular destination?

Not on Friday afternoon ;) Do you envision their reactions could be
different even though both ultimately can't repair the failure?
Amazing how conversations seem to start on Fridays...

The difference could be based on what type of topology change has occurred. Based on the updates, a router can determine if any elements have failed & then whether the associated routers could potentially locally repair them.
Basically, we have the following 5 cases:
1) Topology changes are added links and/or metric cost changes. PLSN can be used regardless of whether all the routers local to the change can do IPFRR.
 2) The only topology change is a single failure - whether node, link,
or SRLG. All the routers local to the change can do IPFRR. PLSN can be
safely used.
 3) The only topology change is a single failure - whether node, link
or SRLG. One or more routers local to the change does not do IPFRR. PLSN
shouldn't be used - because it delays the convergence & traffic is being lost.
 4) The topology change contains multiple failures. PLSN probably
can't be safely used. Theoretically, some of the IPFRR alternates might
still be good - but it's not clear how easy that is to determine or safe to
 5) The topology change contains a failure and at least one other change
(added link or cost change). I think that this case can apply PLSN.
Thinking about this a bit more, I think that the draft may need some words
about the handling of different topology event combinations. What do you

Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>