> Could you outline the changes to the proposal since we discussed it in
> detail last year?
> I believe that the same objections were raised to it in Paris as came
> out of the design team discussion. Certainly, I believe that I voiced
> the same concerns. These related to the much larger convergence time,
As I said to Joel, Pierre François did simulations with the completion
messages on real ISP topologies and his simulations show that sub-second
ordered convergence is possible. If the WG is interested by such
simulation results, we could write a short technical report and make it
available. I don't think that an IETF draft would be the best place to
report simulation results.
> the amount of additional signaling
The completion messages are used to speed up the convergence. Each
router sends at most one completion message per link. This is not a
significant amount of signalling.
> and the clear handling of SRLGs
There are two types of SRLG to consider :
- SRLGs were all links are attached to a router, such as line card
up/down. In this case, the ordered FIB update can be used as a single
message is sufficient to describe the SRLG change
- SRLGs with links attached to different routers. In this case, we can
find an ordering for N common link downs and N common link up events
together. However, the main issue with such types of events is that
routers will not flood their link state packets describing the SRLG
change exactly at the same time. This is a common problem to all
solutions that have to deal with SRLG events. There are two possible
1. Wait until all link state packets corresponding to the SRLG have been
2. Consider that, as soon as one event with an SRLG has been received,
all the links of the SRLG have the same event
I would suggest that to handle events with links attached to different
routers, a safe approach would be to consider such events as an urgent
failure and not apply an ordering.
For the nodes, the document describes how to support router up and
router down events (aka overload bit transitions in ISIS)
In addition, a clear algorithm for the computation would be
We can update this part if you believe that it is not clear enough.
> I can certainly see some uses for the maintenance (link up or metric
> change) related events. The signaling part could use more details
I think that the draft would be useful for maintenance operations
independently of the fast reroute work being done in this WG. Concerning
the signaling part, we would need to write a specific draft for IS-IS
and another one for OSPF. I guess those drafts should be submitted to
the isis and ospf working groups.
> and discussion of the dynamics.
Could you elaborate what you mean by dynamics ?
Thanks for your comments
Rtgwg mailing list