[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: Alia Atlas
Date: Mon, 22 Nov 2004 12:39:15 -0500
Hi Stewart,

At 09:38 AM 11/18/2004, Stewart Bryant wrote:
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.
It is useful to consider known SRLGs. This reduces the traffic impact from
having SRLGs in the network, and they certainly exist.
Nothing is trying to solve uncorrelated failures that happen
simultaneously; it's unclear how one would in anything
  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.
Presumably, there is the work of either pruning the topology or tracking
the SRLGs used in a path.
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
Does this increase for SRLG coverage or have you not really thought about
it? I.e., can the same computation find an alternate with SRLG coverage
and, if no such alternate exists, an alternate without SRLG coverage?
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.
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.
I was referring to three different aspects. One is, as you mention, the
extra time for a tunnel approach to obtain the necessary MPLS labels to
allow protection of LDP traffic. The second is how are the tunnel
endpoints set up in advance? Is this that they are set up when the network
is configured to support IP FRR? Do they need to be set up when it is
determined that an alternate tunneled to that endpoint is
desirable? Third, and more of an internal router issue, is the amount of
time that it may take to configure the router to create a way of sending
traffic into that tunnel.
I am also concerned about the impact of tunnels on fragmentation. There
are also the cases where a packet that is tunneled is tunneled again
because of a second failure; this isn't supposed to be protected against,
but it would be good to not break badly. On the other hand, the draft is
suggesting secondary and even tertiary tunnel encapsulation...
   b) What is the coverage for node protection with this method?
100% with our normal single point of failure and asymmetric link cost
caveats.
K. So can you get 100% coverage for node protection in all 2-connected
networks with symmetrical costs? Is this with a single primary repair or
are you thinking of secondary etc repairs?
What can you get with a single primary repair?

   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.
Thanks.  That made it clearer.

   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.
Aren't you running an SPF rooted at each neighbor of E already for the node
protection case to proxy for the destinations that are reached via that
neighbor?
         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.
What was the typical number of neighbors of E in the example
topologies? How much of an improvement was this over the worst case of an
additional SPF per neighbors' neighbors?
         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.
I'm still not convinced about the complexity of computing and determining
these secondary and tertiary repair paths.
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.
Well, I think that you know that I disagree about paying the price of
complete coverage in the mechanism. :-) This added complexity feels like
overkill; minor changes in network design are sufficient to get there.
If you think of the problem as being solved on two fronts - network design
and SPF/protocol mechanisms, then the mechanisms needed can be reduced to a
manageable complexity.
We already have 2 points on the spectrum. In the first point, the
mechanism is just ECMP and the bulk of the work is in the network design to
get ECMP paths everywhere; this is difficult for network
design. Therefore, we have the second point, where loop-free alternates
are used and the network design needs to be modified to get loop-free
alternates everywhere. This is still considered (by some for some
networks) to require too much network design to be practical.
That's why we're looking at the advanced methods for IPFRR.

Given that asymmetric link costs and SRLGs do exist, it isn't clear that any method short of completely source-routed tunnels will provide guaranteed complete coverage to all 2-connected networks. Certainly none of the others can do so.
Then what is the proper level of mechanism complexity versus network design
complexity? Is it using a new protocol just to obtain resiliency?
We need to arrive at a method that is simpler and easier to use than
RSVP-TE source-routed tunnels. Otherwise, the only benefit we'd get from
an advanced IPFRR method is that it "isn't MPLS", and that's not sufficient
IMHO.
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.
Agreed. As I mentioned at IETF, I'd like to include some of this into the
loop-free alternates draft.
Alia


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

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