[email protected]
[Top] [All Lists]

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

Subject: questions on draft-bryant-ipfrr-tunnels-01.txt
From: Alia Atlas
Date: Mon, 15 Nov 2004 17:13:58 -0500

Have you had a chance to look at the questions I sent out about your draft a few weeks ago (now that IETF is over :)?

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

Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>