Friday, October 15, 2004, 11:17:15 AM, Don Fedyk wrote:
> - I'm O.K. with DELAY_TYPEB timers at this length.
> - But I think DELAY_TYPEC > time for an immediate neighbor to install an
> This value is probably not very long (in the order of 100msec). In my
> understanding Delay_TYPEC starts ticking very close to the time that updates
> are being sent from C to B (In the Figure 1 the immediate neighbor). Once
> B has its alternates in place, C can forward to B with no issues.
> So I suggest:
> DELAY_TYPEB > fault-propagation-time
> DELAY_TYPEC > time for an immediate neighbor to install an alternate.
Don, as I mentioned in one of my previous messages, actual delays mentioned in
the document are not mandatory and are configurable, so it is perfectly fine to
take them down if implementations in the network calculate routes fast enough.
Regarding your suggested equations above, here's what the draft says about
> where fault-propagation-time is the time it is expected to take
> routers in the network to propagate new link-state information, cal-
> culate the new SPT, check the safety condition of the neighbors, and
> install required FIB entries.
As I mentioned in my reply to Olivier, this is not network-wide propagation
time, but only the time for propagation within a certain proximity where there
is dependency between type-Bs and type-Cs. Keeping this in mind,
fault-propagation-time is already what you're looking for.
I chose 2 seconds only to be on the safe side to make sure that people who
follow the spec word to word can deploy their implementations and it will
work with default settings.
> I suppose one could then ask: Could I live with no timer on C?
Not really. We would then not remove the uncertainty about FIB update time
compared to a type-B and would still get microloops if C's new primary is
type-B and used to route to us.
Rtgwg mailing list