At 02:22 PM 6/3/2005, Alex Zinin wrote:
> Also in Section 3.1, with the fallback policy, it might be useful to
> describe how this interacts with the standard SPF hold-down policies that
> currently exist.
When I thought about this, I ended up concluding that all this document can
define is what needs to be done in order for the described mechanism to
work, and then leave interactions with possible SPF hold-down
implementation details to the implementations. I'm open for suggestions
though, so if you had an idea on what it might look like--please send it.
I'll think about it more. Off-hand, I'm tempted to say that if an SPF
hold-down is in force, then PLSN shouldn't be used. I.e., only use PLSN if
the topology has been stable for long enough that all routers will delay
only DELAY_SPF before computing - and not more.
> 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.
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?
Rtgwg mailing list