[email protected]
[Top] [All Lists]

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

Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt
From: Stewart Bryant
Date: Thu, 18 Nov 2004 14:38:22 +0000

Alia Atlas wrote:


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?
It was a simplification. We were completely sure of the voracity
of the scheme in the non-SRLG case, but had not analyzed the
SRLG case.

We also have concerns about the relative frequency of known SRLGs
members vs unknown SRLG members. Clearly if the proportion of
unknown SRLG members is significant, then the usefulness of SRLG
aware repairs is questionable. We decided that we really needed
some answer to this question before pursuing this additional
complication to the solution.

  a) Is there something about the proposed method which makes it
impractical to provide SRG protection?
SRLGs require an analysis of the SRLG behavior of the routers
on the proposed repair path. This is relatively straight forward
since P and Q space can trivially be trimmed to exclude SRLG traversals, but the resultant connectivity may require us
to perform a secondary repair analysis.

  b) What is the additional computational complexity to provide such
Almost nothing if a primary repair is feasible. Then about as much
work as a secondary repair calculation per SRLG that must be traversed.

  c) What are the ramifications of SRGs for the coverage?

It really depends on the topology, but it may result in no solution.
However to put this in context, it is not clear that this approach
will be worse than any of the other proposed approaches in terms
of finding a solution if one exists. Indeed the contrary is more
likely i.e. with the longer reach of this approach we are more likely
to find a repair where one is possible.

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
We do not understand. The tunnel endpoints are set up in advance
and only used when needed. To the repairing router a tunnel looks
just like any other next-hop and takes the same time to cut over
to, and to set up. Of course when this is an MPLS network we
have to get the labels, but that is the case for any multi-hop
repair strategy and has to be done in advance.

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?
No, we need both link and node protection.

         Do the interference scenarios never exist for link protection?

There is no interference to link protection, although with SRLGs this

   b) What is the coverage for node protection with this method?
100% with our normal single point of failure and asymmetric link cost

   c) Could you explain the example in Figure 9?  I don't see why the
      traffic would have a 50% probability of looping.
The furthest that S can reach is K - via DF from L.
K has an equal cost path split for destination S1 via K-L-S-E-S1
and K-J-I-E-S1. The former path would cause a loop.

   d) Could you clarify what you are seriously suggesting to avoid the
problem of looping secondary repair paths?
We encapsulate to I in the above case. To solve the more general case
we need to run a computation at each of the neighbors of E that can
be reached via a primary path, until you find a solution.

         What is the
associated computational complexity of that?
It is highly topology dependent, because as K increases the number
of SPFs increases, BUT so does the richness of the connectivity
and therefore the search completes earlier. Mike did some analysis
of the number of SPFs per node in our set of example topologies.
The typical number of SPFs per node was 12, with a worst case of 80
for a tiny number of nodes. However you need to note that most
of these SPFs complete as a very small radius - as soon as a
solution was found.

         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).
See above.

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.
To some extent this is the price of complete coverage. But the
alternative of incomplete coverage may be more unpalatable. The
SRLG extensions seem to need no new techniques, just greater
application of the ones we have already described.
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.
Yes. Indeed you could argue that MHPs are the most important prefixes
to repair - that is why they were MHP.

The concern about the node failure detection mechanism is interesting
and applies equally to loop-free link-protecting alternates.

- Stewart

Rtgwg mailing list
[email protected]

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