Hi Mike & Stewart,
I have a number of questions on your updated draft as follows.
1) Why is shared risk group protection an explicit non-goal?
a) Is there something about the proposed method which makes it
impractical to provide SRG protection?
b) What is the additional computational complexity to provide such
c) What are the ramifications of SRGs for the coverage?
2) From the description of computation, it appears that you must
calculate at a minimum:
1 reverse SPF per neighbor N_i
1 reverseSPF per neighbor's neighbor R_i_j
To handle the extended F-space, you need an additional SPF per
neighbor N_i; this is the same computation needed for loop-free
alternates, though, and so could be assumed as already available.
4) Tunnel set-up time is also important and should be described. For
the duration of the tunnel set-up time, there will be unprotected
6) You state that this method can provide complete protection against
any single failure (except for single points of failure and asymmetric
link costs), but then have an example for interference between
potential node repair paths.
a) Are you considering that only link protection is necessary for
the coverage? Do the interference scenarios never exist for
b) What is the coverage for node protection with this method?
c) Could you explain the example in Figure 9? I don't see why the
traffic would have a 50% probability of looping.
d) Could you clarify what you are seriously suggesting to avoid the
problem of looping secondary repair paths? What is the
associated computational complexity of that? It seems to be
rather high, depending on the number of routers to which S could
establish repair paths as well as the number of neighbor's
neighbors to which repair paths haven't been established. This
seems to me to be excessively complicated (both to compute and
as a mechanism).
The number of enhancements and complicated details left out of scope
is certainly a concern. It does seem to me that as you flesh out this
idea, the corner cases make it even more complex.
On the positive side, I think that the section multi-homed prefixes is
quite useful; the base spec draft should say something about this as well.
The concern about the node failure detection mechanism is interesting
and applies equally to loop-free link-protecting alternates.
Rtgwg mailing list