Subject: RE: I-D ACTION:draft-zinin-microloop-analysis-00.txt

From: "Don Fedyk" <[email-masked]>
Date: Fri, 15 Oct 2004 14:17:15 -0400

Hi Alex

In the draft:

>Type C:
> Installation of the new route is delayed by time DELAY_TYPEC.
> Until then, the router continues to use its old next-hops.

>DELAY_TYPEB and DELAY_TYPEC are two configurable constants. They
>should be configured with the same value on all routers in the net-
>work and such that following equation is true:
>
>DELAY_TYPEB > DELAY_TYPEC > fault-propagation-time
>
>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.
>
>Suggested default values for DELAY_TYPEB and DELAY_TYPEC are 4 and 2
>seconds correspondingly.

- I'm O.K. with DELAY_TYPEB timers at this length. 
- But I think DELAY_TYPEC > time for an immediate neighbor to install an
alternate. 
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.  I
suppose one could then ask: Could I live with no timer on C?  

Regards,
Don 

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: Alex Zinin <[email-masked]>
Date: Fri, 15 Oct 2004 17:44:45 -0700

> 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

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

Alex