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