Subject: questions on draft-bryant-ipfrr-tunnels-01.txt

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Oct 2004 22:52:14 -0400

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
protection?
   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
traffic.

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
       link protection?
    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.

Alia

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