[email protected]
[Top] [All Lists]

Type-C & FRR repair

Subject: Type-C & FRR repair
From: Alex Zinin
Date: Fri, 3 Jun 2005 16:57:10 -0700

>> > 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

> 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?


Rtgwg mailing list
[email protected]

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