> Just a few comments on the updated draft...
> In Section 3.1, it might be worth clarifying that more updates might be
> expected than just the other end of a point-to-point link. That might make
> it seem that a router could start its delayed SPF once the second update
> had arrived.
> 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.
> In Section 3.2, case 2, I believe that for the ECMP case, it isn't possible
> to have, for a destination, some next-hops that are type A and some that
> are type C. If there's at least one next-hop that is type A, then that
> provides the not-this-primary next-hop that is safe for type B.
I think you're right. Will remove the second part in the "()".
> 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.
Rtgwg mailing list