Alia Atlas wrote:
Stewart,
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 :)?
Thanks,
Alia
I have a number of questions on your updated draft as follows.
1) Why is shared risk group protection an explicit nongoal?
It was a simplification. We were completely sure of the voracity
of the scheme in the nonSRLG 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
protection?
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
Correct
To handle the extended Fspace, you need an additional SPF per
neighbor N_i; this is the same computation needed for loopfree
alternates, though, and so could be assumed as already available.
Yes.
4) Tunnel setup time is also important and should be described. For
the duration of the tunnel setup time, there will be unprotected
traffic.
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 nexthop 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 multihop
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
changes.
b) What is the coverage for node protection with this method?
100% with our normal single point of failure and asymmetric link cost
caveats.
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 KLSES1
and KJIES1. 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 multihomed 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 loopfree linkprotecting alternates.
Yes.
 Stewart
_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg
