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

From: Alia Atlas <[email-masked]>
Date: Mon, 15 Nov 2004 17:13:58 -0500

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Nov 2004 14:38:22 +0000

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
> 

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.

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

>>    1 reverseSPF per neighbor's neighbor R_i_j

Correct

>> alternates, though, and so could be assumed as already available.

Yes.

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

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

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

>>       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
>>       seems to me to be excessively complicated (both to compute and

See above.

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

>> quite useful; the base spec draft should say something about this as 

Yes. Indeed you could argue that MHPs are the most important prefixes
to repair - that is why they were MHP.

>> and applies equally to loop-free link-protecting alternates.

Yes.

- Stewart

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 18 Nov 2004 12:10:10 -0500

In message <[email-masked]>
> complication to the solution.

If unknown SRLG is a problem and not supporting SRLG makes all SRLG
behave like unknown SRLG, then an approach which does not support SRLG
is more problematic than an approach which does support SRLG.  The
only case where the two are equal (approaches that do and don't
support SRLG) is where SRLG do not exist which we know is not the case
in any real network.

Therefore I think any argument opposing the support of SRLG due to the
possibility (or certainty) that unknown SRLG will exist is quite flawed.

For example, WDM introduces SRLG that have to be considered for a fast
restoration approach to be at all viable.  Logical links that traverse
hundreds of miles on the same fiber are going to have a high
percentage of correlated failure.

Curtis

ps - we not return you to our regularly scheduled arguments about why
SRLG are a hard problem for some approaches.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 19 Nov 2004 12:28:53 +0000

OK, we will describe how to handle SRLG in the next version.

However unknown SRLGs will affect all solutions, so if
SRLG is a MUST, then all solutions need text describing
their behavior under conditions of unknown SRLG. In
particular unknown SRLG can result in mutually looping
repairs (which could even be cyclic) and the solution
must describe how to detect and break these loops.

> SRLG are a hard problem for some approaches.

If tunnels were to perform a per prefix search for a two hop
solution the results would be identical to that of U-turn.
Therefore tunnels are a true superset of the U-turn approach.
For simplicity we did not describe this per-prefix search,
because we achieved complete coverage without it in all the
networks we examined.

However give that tunnels are a superset of U-turns, then
any SRLG issue applies equally to both.

- Stewart

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 19 Nov 2004 10:16:09 -0500

In message <[email-masked]>
> must describe how to detect and break these loops.

MPLS RSVP/TE FRR is loop free in the presense of unknown SRLG.  At
worst the fast restoration fails and a new LSP is needed from ingress
to egress.  So the worst case is a slow restoration but not a loop.

If you meant all IP FRR can be subject to transient looping due to
unknown SRLG, then you are correct.  That is a consequence of
hop-by-hop forwarding.  IP itself is subject to transient looping due
to correlated failures even without IP FRR.  We seemed to have lived
with it so far.

With the greater empahsis on reliability and fast restoration of
service in todays commercial backbones, providers need to be vigilant
in maintaining their SRLG database.  Its easy to swap circuits and not
update the database, etc.  I've seen two carriers handle this, one
very well and one not very well.  Many providers who have leased
"disjoint circuits" from a carrier whether internally or external
lease (and paid a premium for that) have had them both go down due to
failure of a common resource that the carrier failed to consider or
had the circuits swapped in a maintenance or circuit grooming such
that they were no longer disjoint.  This is less a problem the higher
up you go on the food chain because the SRLG database is more
rigorously maintained.

Providers that don't care about fast restoration need not keep an up
to date SRLG database, or keep one at all.  If so, they are kidding
themselves if the run any form of FRR.  Just my opinion.

I don't know that the WG has decided that SRLG is a MUST.  It should
be obvious from what I've written that I think its important.

> any SRLG issue applies equally to both.

Could you please explain how a two hop per prefix search addresses
SRLG and perhaps address the time complexity of the algorithm.  It is
not at all clear what sort of algorithm you have in mind from the
description above.  I'm assuming that this was supposed to be just a
quick explanation and you are not suggesting that this would be an
adequate entry in the draft to address SRLG.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 12:39:15 -0500

Hi Stewart,

>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

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

>>>    1 reverseSPF per neighbor's neighbor R_i_j

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?

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

>100% with our normal single point of failure and asymmetric link cost

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?

>and K-J-I-E-S1. The former path would cause a loop.

Thanks.  That made it clearer.

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

>of these SPFs complete as a very small radius - as soon as a

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?

>>>       seems to me to be excessively complicated (both to compute and

I'm still not convinced about the complexity of computing and determining 
these secondary and tertiary repair paths.

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

>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

---

From: Naiming Shen <[email-masked]>
Date: Mon, 22 Nov 2004 10:01:33 -0800

Alia,

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

It does not have to be "MPLS" if you consider the IP TE mechanism though
:-)

Regards,
- Naiming

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 13:14:36 -0500

>must describe how to detect and break these loops.

Unknown SRLGs are uncorrelated failures.
The detection of uncorrelated failures is by the IGP, which can then 
install the new primaries as quickly as possible.  In the meantime, traffic 
loops until TTL expires.

IPFRR is quite clearly not handling uncorrelated failures; no protection 
mechanism that I am aware of does.

>Therefore tunnels are a true superset of the U-turn approach.

In terms of alternates provided, but not in terms of forwarding or complexity.

>any SRLG issue applies equally to both.

The algorithm for computing U-turn alternates is a bit different from the 
algorithm that you are using to look for tunnels.

Therefore, the computational impact of SRLGs may be different as well.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 13:27:09 -0500

Hi Naiming,

At 01:01 PM 11/22/2004, Naiming Shen wrote:
>>an advanced IPFRR method is that it "isn't MPLS", and that's not 
>>sufficient IMHO.
>

Sure.  We can have a different protocol in the network solely for 
resiliency to create those source-routed tunnels with the associated 
complexity, but at least it wouldn't be MPLS :-)

I do think that the complexity of the mechanism we select for an advanced 
IPFRR method has to be bounded by a consideration of what other potential 
solutions exist.

If a mechanism is more complicated to understand, manage, and configure 
than RSVP-TE, then I think we need to seriously consider where the benefit is.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 13:29:55 -0500

>to egress.  So the worst case is a slow restoration but not a loop.

This is true, but only for the length of the TE tunnel.  TE gets this 
benefit only because it is an overlay approach; the issue occurs where ever 
the overlay ends.  If one is doing 1 or 2-hop tunnels, then looping is also 
possible.

>to correlated failures even without IP FRR.  We seemed to have lived

Part of the question is how often do uncorrelated failures happen as 
compared to single failures (which could also be a known SRLG)?  If 
uncorrelated failures are relatively rare in comparison, then the trade-off 
of saving the traffic via an IPFRR alternate for the single failures in 
exchange for potentially looping saved traffic for an uncorrelated failure 
seems reasonable to me.

>be obvious from what I've written that I think its important.

I also think that SRLGs are important.  We do need to have the basic 
mechanisms understood before trying to add the additional complexity of 
SRLG handling.  I certainly think that the ability to handle SRLGs is an 
important criterion in considering different approaches.

Alia

---

From: mike shand <[email-masked]>
Date: Mon, 22 Nov 2004 18:59:50 +0000

>What can you get with a single primary repair?

Some examples of the percentage of node repairs which require secondaries 
below. This is calculated by taking the number of repairs for node repair 
which require a secondary repair divided by the total number of repairs. 
Where a repair is a repair to a single neighbor's neighbor.

e.g.
           V
           |
S---------E----U
           |
           T

The repairs for node E failing would be

SV,SU,ST
VS,VT,VU
etc.

0.79%
13.77%
3.98%
1.47%
0.50%
4.64%
0.00%

(Note that the 13% one is a hub and spoke like network which gives only 
about 70% coverage for U-turns (link repair; I haven't simulated U-turns 
for node repair).  It is quite a nasty topology for any IPFRR mechanism)

         Mike

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 14:38:45 -0500

In message <[email-masked]>
Alia Atlas writes:
> Unknown SRLGs are uncorrelated failures.  The detection of
> uncorrelated failures is by the IGP, which can then install the new
> primaries as quickly as possible.  In the meantime, traffic loops
> until TTL expires.
>  
> IPFRR is quite clearly not handling uncorrelated failures; no
> protection mechanism that I am aware of does.

Alia.  

I think we have a terminology problem here.

Unless I'm mistaken correlated failures are simply ones that happen at
about the same time.  Just because someone didn't realize that two
logical links used a common physical resource (unknown SRLG) doesn't
mean the failures were not correlated.  For example, when the
earthquake outside San Diego took out three of four major fiber paths
in the mid 1990s, the failure was definitely correlated.  It was not
anticipated and would not have been listed in a set of SRLGs but after
it happenned it didn't take much to figure out that the failures
shared a common cause leading to them occurring at about the same time
(correlated with known cause).  Failures can also be correlated
without a known cause of the correlation.  This is when at least
initially no one knows why but for some reasons two (or more) circuits
are observed failing at the same time.  Again there is no SRLG entry.

There is work in the literature on handling multiple failures.  One
simple way is to make path B disjoint with path A.  Then make path C
disjoint with path A and B.  Obviously I'm oversimplifying for
illustration.  If two correlated failures occur that are not
anticipated, then all three paths can't go down.  OTOH .. a third
failure will take them all down.  I don't know that this is considered
practical for most data communication problems (perhaps NASA or the
military has a need for this - war has a way of causing correlated
failures that are not planned for so maybe there is an application,
though that is a reason that connectionless networking got started).

> The algorithm for computing U-turn alternates is a bit different from
> the algorithm that you are using to look for tunnels.
>  

I think what this is leading to is whether it is a requirement that
techniques address SRLG and if so whether it is also a requirment that
the proposed SRLG solution (or overall solution) is computational
practical.  The latter would seem to be consistent with routing area
scalability requirements.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 14:41:02 -0500

Mike,

Thanks.  That's very interesting.  For the primary repairs, can you get the 
percentages that require the directed forwarding?  I'm curious to see if 
the benefit comes from less restricted tunnels or the extension via the 
single end-hop source routing.

For the U-turn alternates, on the topologies I've got, I found about 72% 
node protection.  That's a percentage of the src/dest pairs covered.

Alia

---

From: Naiming Shen <[email-masked]>
Date: Mon, 22 Nov 2004 11:47:24 -0800

Hi Alia,

> complexity, but at least it wouldn't be MPLS :-)

Well, the main purpose is to enable backbone IP tunnels with the
capability of TE, IPFRR is just a side effect of that :-)

> 
> I do think that the complexity of the mechanism we select for an 
> advanced IPFRR method has to be bounded by a consideration of what other 
> potential solutions exist.
> 

I agree with finding the simpler solution approach, but I disagree that
the RSVP-TE or NFRR to be "complicated" solution though...

Regards,
- Naiming

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 14:52:45 -0500

> the overlay ends.  If one is doing 1 or 2-hop tunnels, then looping is also 

There is still no possibility of routing loops in multiarea TE.

Actually it is a benefit of source specified forwarding.  So something
like NIMROD would have the same benefit even though it is
significantly different from MPLS RSVP/TE.  NIMROD is not an overlay.

> exchange for potentially looping saved traffic for an uncorrelated failure 

Again - terminology.  Uncorrelated failures would be ones that don't
happen at the sake time.  I still got what you said.

Yes the tradeoff is probably worth it.  The point that I was trying to
make is you *can't* loop with MPLS/TE and you *can* loop with IP even
without IP FRR.  Looping is really bad since you affect other triaffic
if you congest links going around long enough for TTL to expire.

> important criterion in considering different approaches.

Its nice to be in agreement.  A real good question for providers
though is given the widespread use of TDM or switched services in low
speed, and WDM in high speed networking, is IPFRR useful without SRLG.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 14:58:19 -0500

> It does not have to be "MPLS" if you consider the IP TE mechanism though

True.  But the IP TE is so similar to MPLS TE that the objection to
MPLS TE (which I personally think is FUD) involves the effort to
manage it.  If you configure MPLS TE for zero bandwidth then the main
difference is the forwarding.  An autoconfig for MPLS TE to set up a
tunnel to all IGP nodes (for example) would eliminate any management
overhead.  If IP FRR were considering such solutions, then that would
seem to me to make more sense than IP TE (why reinvent the wheel).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 15:09:14 -0500

> for node repair).  It is quite a nasty topology for any IPFRR mechanism)

So what you are saying seems to be that covering the node disjoint
problem is mostly not needed.  I think some providers would dispute
that (if providers ever did speak up in IETF and if one does please
disregard my speculation on what providers might say).

Also this does not address SRLG at all which was another part of this
thread.  Thats why I changed the subject line.  You could further
split that into node disjoint and SRLG since they are different
problems (though the node disjoint problem can be considered a proper
subset of SRLG).

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 15:52:56 -0500

Curtis,

You may be right on the terminology.

What about unexpected simultaneous failures?  One can do a mechanism, as 
you said, to protect against a limited number of unexpected simultaneous 
failures, but not a large or arbitrary number without fair expense.

Alia

>though that is a reason that connectionless networking got started).

...
>scalability requirements.

Yes
.
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 16:00:20 -0500

>There is still no possibility of routing loops in multiarea TE.

For the traffic in the full overlay.

>significantly different from MPLS RSVP/TE.  NIMROD is not an overlay.

Sure.  But this works only for the region where the traffic is following 
source specified forwarding; as soon as there's a local decision, it's back 
to the possibility of loops.

>if you congest links going around long enough for TTL to expire.

Any time you go back to hop-by-hop forwarding, you can loop.  The only way 
that MPLS/TE avoids it is with a full overlay.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 16:03:35 -0500

Hi Naiming,

>capability of TE, IPFRR is just a side effect of that :-)

Coming full circle, I suppose.  :-)
If a network is already doing TE and is willing to do the configuration, 
etc., then it makes sense to use TE Fast-Reroute.  Whether the forwarding 
path is MPLS or IP seems irrelevant to me in that piece of the discussion.

>the RSVP-TE or NFRR to be "complicated" solution though...

Since that's what I started with and a requirement for something simpler 
for those not interested in TE, I do think of it as the upper bound on the 
acceptable complexity.  Whether that makes it "complicated" is a matter of 
opinion.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 16:05:22 -0500

Curtis,

I think that Mike's numbers are for the percentage of node failures that 
can't be repaired with a single primary tunnel+directed forwarding.

I.e., it covers the node disjoint case pretty well.

Alia

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 17:20:10 -0500

> failures, but not a large or arbitrary number without fair expense.

Thats already in another response.  Briefly, unexpected simultaneous
failures are covered in the literature but the solutions may not be
practical for commercial data communications.  It usually just called
multiple failures in the literature that doesn't specificly address
SRLG even where the algorithms would still be applicable with SRLG.

Curtis

---

From: Naiming Shen <[email-masked]>
Date: Mon, 22 Nov 2004 14:23:06 -0800

> seem to me to make more sense than IP TE (why reinvent the wheel).

As I mentioned in the previous email, IP TE is really for the backbone
IP tunnels. And IP TE not only handles the IPFRR, it does the
IP multicast FRR also, and optionally it can handle LDP and RSVP related
MPLS LSPs, since I don't imagine anyone would say they only want
pure MPLS solution FRR, no IP solution can be tolerated ;-)

On the other hand I will be happy to see a simpler solution
even if it can not do IP multicast FRR.

Regards,
- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Mon, 22 Nov 2004 14:33:09 -0800

Hi Alia,

> Coming full circle, I suppose.  :-)

The reason it seems comming to a full circle is that, I keep waiting for
a simpler solution, and yet to see one ;-)

> etc., then it makes sense to use TE Fast-Reroute.  Whether the 
> forwarding path is MPLS or IP seems irrelevant to me in that piece of 
> the discussion.

I thought that was relevant in this IPFRR discussion, otherwise there is
no way the NFRR solution should be outside this discussion. In terms of
configuration "complication", it's all relative thing. People need to
do comparison for their network in order to reach some conclusion.
Also, the NFRR or MPLS TE configuration is mostly implementation issue,
majority of that can be automated just like the IPFRR approaches
discussed in this working group.

Cheers,
- Naiming

>>> advanced IPFRR method has to be bounded by a consideration of what 
>>> other potential solutions exist.
>>> If a mechanism is more complicated to understand, manage, and 
>>> configure than RSVP-TE, then I think we need to seriously consider 
>>> where the benefit is.
>>
>>
> for those not interested in TE, I do think of it as the upper bound on 
> the acceptable complexity.  Whether that makes it "complicated" is a 
> matter of opinion.
> 
> Alia
> 
> 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 17:35:05 -0500

> I.e., it covers the node disjoint case pretty well.

What he's saying is that in the worst case he looked at 13.77% of the
cases were not covered by single hop.  With 2 hop there is 100%
coverage but there is still some question about how computationally
feasible the 2 hop algoritm is.

I thought the point of this message was to indicate that node disjoint
1) is covered by the 2 hop case, but 2) is low probability.

My point was that the node disjoint problem is a subset of the SRLG
problem.  It is a subset because you can define a SRLG to be all links
adjacent to a given node and therefore define the node disjoint case
as an SRLG case.  The local SRLG problem is also a subset of the SRLG
problem.

So far only MPLS/TE fully addresses SRLG and it does so very cleanly.

If the general SRLG problem is not addressed, the failure to address
the problem should at least be acknowledged in the documents.  If SRLG
is not a requirement for IP FRR, that should at least be stated in the
framework document, but the limitations should also be acknowledged.

Normally it would be sufficient to list something as future work in
the framework but that should be done where algorithms are known and
only the protocol bits need to be defined later (and if needed).  In
this case there is question about whether feasible algorithms exists
so the limitation should be acknowledged and not just dismissed.

I personally think that an important requirement for an IP FRR
technique is that feasible algorithms for SRLG be known so the product
of the WG isn't a dead end.  So far there doesn't seem to be WG
concensus either way.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 17:55:22 -0500

> even if it can not do IP multicast FRR.

You definitely have an advantage in providing FRR for IP multicast.  I
question whether that is a requirement for anyone.  FRR seems to be
popular among those doing VOIP which is unicase, and VPNs.  The VPNs
are typically LDP.  Often the VOIP resides within an LDP VPN.  There
is existance proof that you can run VOIP over LDP over MPLS/TE quite
nicely and use MPLS FRR.

So far there hasn't been a lot of interest in multicast over MPLS
because those providers doing MPLS are not seeing a lot of multicast
traffic (and some don't offer native multicast) so they are fine with
offering multicast over IP with no TE or FRR.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Nov 2004 18:25:12 -0500

> a simpler solution, and yet to see one ;-)

I think this work exists due to anti-MPLS sentiment and a need for
FRR.  The alternative (IP FRR) may be proving to be problematic and
the argument that there is something hard about doing MPLS FRR seems
to be losing credibility )or maybe just more so when FRR is added to
the list of requirements).

> discussed in this working group.

Yep.  Agree completely.  The requirement *not* to use MPLS may not be
based on any technical issue.

Anyway we may be either out of scope or committing herasy as far as
this WG is concerned.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Mon, 22 Nov 2004 20:33:48 -0500

Curtis,

>as an SRLG case.  The local SRLG problem is also a subset of the SRLG

Local SRLGs and node disjoint are easier cases to handle than general 
SRLGs.  Certainly, if one solves the general case, those can come for free.

One issue that I see for the non-source-routed tunnel based approach is 
that it uses the original next-next-hop as a proxy for a set of 
destinations.  It is possible that the path from the next-next-hop to a 
particular destination will not be available because it traverses a link in 
the same SRLG.

I think that this may make the destination assignment a bit trickier.

>So far only MPLS/TE fully addresses SRLG and it does so very cleanly.

In a full overlay, MPLS/TE requires a CSPF per IGP node.

If we were willing to accept an SPF per node in the topology, then looking 
at SRLGs would be a lot simpler!

If I were even willing to accept an SPF per neighbors' neighbor, it would 
be completely clear how to do SRLGs for U-turn alternates.

The computational complexity for MPLS/TE can be quite large, depending on 
the number of tunnels to be considered.  Sure, one can use techniques to 
minimize the impact, but it is there.

I'd say it's clear that for IP FRR, there's a desire to have substantially 
fewer SPFs than 1 per node.

There is the basic fact that without source-based routing, it might not be 
possible to find an alternate.

>so the limitation should be acknowledged and not just dismissed.

I guess it depends on the particular technique considered, but there are 
feasible algorithms for some of them.

For loop-free alternates, one can track the SRLGs traversed by each 
neighbor, and decide whether to use a loop-free neighbor based on whether 
the SRLGs of concern are passed.

Alia

---

From: mike shand <[email-masked]>
Date: Tue, 23 Nov 2004 09:40:33 +0000

>can't be repaired with a single primary tunnel+directed forwarding.

Correct. Yes I was puzzled by Curtis' comment too. What these figures say 
is that MOST node failures can be repaired using primary tunnels only, and 
that the remaining few percent can be repaired using a secondary tunnel. 
i.e. repair to one neighbor's neighbor and then let that node repair again. 
(note that this is not nested tunnel encapsulation, since the packet is 
decapsulated before being re-encapsulated. Indeed, it is often the case 
that one (or even both) of the repairs would not need tunnels at all. i.e. 
both the primary and secondary repair could be LFAs. But note that to avoid 
the problem with looping secondaries we would encap the first repair, 
although this isn't strictly necessary in all topologies; it could be 
avoided in some topologies at the expense of extra computation (to 
determine if it were necessary).

         Mike

Alia, these may not be in the form you would like (but since I have them to 
hand....).

These are the same networks as before. df% is the percentage of repairs 
which required directed forwarding (the same as before, the fraction of 
individual repairs which needed DF). LFA% is the percentage which simply 
used LFA (i.e. no tunnels)
Note that is no tunnels for ALL traffic. This doesn't mean that this is the 
percentage of traffic which would not be tunnelled. That would be much 
higher, since we can easily do per destination LFA determination.

In case that is not clear, let me elaborate for the simple link failure 
case. We can compute a repair for the failure of SE. Sometimes we can 
repair ALL traffic (even that with a destination of E) by using LFA. Other 
times we will need a tunnel to get to E. However, in that case, we can 
compute the set of destinations which have LFAs, and we would only use the 
tunnel for the remaining traffic. Of course it would theoretically be 
possible to compute different tunnels for different destinations, but that 
is not computational feasible.

sec %   df%     LFA%
0.79%   4.6%    69.4%
13.77%  41.9%   45.5%
3.98%   19.1%   66.3%
1.47%   1.2%    59.3%
0.50%   1.3%    79.4%
4.64%   1.3%    61.9%
0.00%   0.0%    62.6%

         Mike

---

From: mike shand <[email-masked]>
Date: Tue, 23 Nov 2004 10:01:40 +0000

>feasible the 2 hop algoritm is.

Yes. Although there being some question is not the same as it being infeasible.

>1) is covered by the 2 hop case, but 2) is low probability.

Yes. 100% of node failures can be covered by using 2 hop, but that is only 
necessary in a small percentage of cases in most topologies, although there 
are some pathological cases where the percentage may be higher.

Yes.

>framework document, but the limitations should also be acknowledged.

I don't think we have ever said it is not a requirement. So far we have 
avoided the complication of discussing it until we get some kind of a 
handle on the simple cases. It has always been the intention to extend the 
solutions to cover (known) SRLG. As stewart has said, as far as the tunnel 
method is concerned, the extension to SRLG is relatively straightforward. 
The computation of F and G space (aka P & Q space) can be trivially 
extended to excise any sub-trees that traverse any SRLG member. If that 
finds a solution then we are done. If not it may be necessary to consider 
"secondary" repairs, and the techniques for doing that are the same as with 
node repair. This is not surprising, since as you point out node repair is 
a case of SRLG.

>so the limitation should be acknowledged and not just dismissed.

Yes I see your point.

>of the WG isn't a dead end.  So far there doesn't seem to be WG

I would tend to agree. It would be useful to ave some other opinions.

         Mike

---

From: mike shand <[email-masked]>
Date: Tue, 23 Nov 2004 10:08:53 +0000

Yes.

>particular destination will not be available because it traverses a link 
>in the same SRLG.
>

Well, by analogy with the node failure case, one way to deal with this is 
to consider a separate repair to the far side of each SRLG. I'm not sure it 
is always necessary, but I think it is sufficeient.

>at SRLGs would be a lot simpler!

Yes!

>fewer SPFs than 1 per node.

Yes, given that some of the networks we have been looking at have getting 
on for 1000 nodes, that would seem a reasonable assumtption.

>possible to find an alternate.

Yes this is always the problem with what are effectively loose source 
routing methods (with various restrictions).

>feasible algorithms for some of them.

Agreed.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 23 Nov 2004 10:09:53 -0500

> Yes. Although there being some question is not the same as it being

Yes, I agree.  As worded "still some question about how
computationally feasible ..." simply says that we haven't seen
anything that assures us that it is computationally feasible.

> I would tend to agree. It would be useful to ave some other opinions.

This is a requirements question so it is time for providers who intend
to use IP FRR to speak up.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Nov 2004 10:58:33 -0500

Mike,

The percentage that is missing is then those that require a single primary 
tunnel for repair?  These are the number for repair for node failure?  I'm 
trying to get a sense of what the benefit from LFA is versus the tunnels 
versus the DF versus the secondary, etc.   I'm interested in the different 
benefits for link protection and for node protection.

In a somewhat related question, I understand that you are using a 
next-next-hop to proxy for destinations.  Is it possible that you miss a 
viable LFA to a destination because of this?  I.e., the neighbor may be LFA 
with respect to the destination but not the next-next-hop?

Also, how do you handle the ECMP cases where you may have multiple 
next-next-hops (even from the same next-hop)?  That seems like a 
per-destination decision.

Thanks,
Alia

At 04:40 AM 11/23/2004, mike shand wrote:
>Alia, these may not be in the form you would like (but since I have them 
>to hand....).
>
>Note that is no tunnels for ALL traffic. This doesn't mean that this is 
>the percentage of traffic which would not be tunnelled. That would be much

---

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Nov 2004 11:03:32 -0500

Mke,
At 05:08 AM 11/23/2004, mike shand wrote:
>to consider a separate repair to the far side of each SRLG. I'm not sure 
>it is always necessary, but I think it is sufficeient.

But what is the far side of the SRLG?  Trimming the trees after they're 
computed makes some sense, but then it a next-next-hop is dependent on the 
same SRLG to reach a destination, that destination won't be given an 
alternate (where there might be one without the proxying).

Alia

---

From: mike shand <[email-masked]>
Date: Tue, 23 Nov 2004 16:26:55 +0000

At 10:58 23/11/2004 -0500, Alia Atlas wrote:
>tunnel for repair?  These are the number for repair for node failure?

Yes, this is all node failure

sec %   df%     LFA%
0.79%   4.6%    69.4%

So what this tells us is that 69% of the repair paths required didn't need 
a tunnel (to get to the nnh), so 31% did require a tunnel. Of these 4.6% 
need DF as well, and 0.8% required a secondary repair (which itself may 
have been satisfied by LFA or required DF).

>  I'm trying to get a sense of what the benefit from LFA is versus the 
> tunnels versus the DF versus the secondary, etc.   I'm interested in the 
> different benefits for link protection and for node protection.

I may have some numbers for link protection....

I should probably re-run the simulations with some better stats, but these 
will do for now.

LFA     DF
82%     1%
78%     12%
73%     20%
89%     1%
79%     0%
78%     1%

All give 100% protection if DF is used where necessary. Of course 
secondaries are not necessary for link repair (except perhaps for the case 
of SRLG).

SO what this

LFA     DF
82%     1%

means is that 82% of links can be repaired without using tunnels. 18% 
require tunnels and these are split with 17% not requiring DF and 1% 
requiring DF.

>next-next-hop to proxy for destinations.

Yes.

>  Is it possible that you miss a viable LFA to a destination because of 
> this?  I.e., the neighbor may be LFA with respect to the destination but 
> not the next-next-hop?

Yes, but that is why I say that in practice we skim the LFA reachable 
destinations off the top, since that computation falls out of the rest. 
That way we only tunnel traffic that HAS to be tunnelled. It would of 
course work if we put this traffic in the tunnel, but it seems sensible to 
avoid using a tunnel where possible.

>per-destination decision.

OK, so you have

S------E-----X
        |
        Y

Traffic for destination D is split through X and Y. You have a choice. If 
you want to preserve (some semblance of) the ECMP, then you split the 
traffic between the repair for X and the repair for Y. Or you can simply 
arbitrarily choose either of X or Y. You have to determine which nnh is 
used for which destination anyway to do the traffic assignment to the 
correct repair even when there is no ECMP. You can do this by noting the 
nnh when you run the normal SPF at S.

         Mike

>>the percentage of traffic which would not be tunnelled. That would be 
>>much higher, since we can easily do per destination LFA determination.
>>
>>repair ALL traffic (even that with a destination of E) by using LFA. 
>>Other times we will need a tunnel to get to E. However, in that case, we 
>>can compute the set of destinations which have LFAs, and we would only 
>>use the tunnel for the remaining traffic. Of course it would 
>>theoretically be possible to compute different tunnels for different 
>>destinations, but that is not computational feasible.
>>
>>
>>sec %   df%     LFA%
>>0.79%   4.6%    69.4%
>>13.77%  41.9%   45.5%
>>3.98%   19.1%   66.3%
>>1.47%   1.2%    59.3%
>>0.50%   1.3%    79.4%
>>4.64%   1.3%    61.9%
>>0.00%   0.0%    62.6%
>
>

---

From: mike shand <[email-masked]>
Date: Tue, 23 Nov 2004 16:48:44 +0000

At 11:03 23/11/2004 -0500, Alia Atlas wrote:
>But what is the far side of the SRLG?

When you run a normal SPF rooted at S, as you traverse each SRLG you will 
find which is the far side.

>Trimming the trees after they're computed makes some sense, but then it a 
>next-next-hop is dependent on the same SRLG to reach a destination, that 
>destination won't be given an alternate (where there might be one without 
>the proxying).

It certainly true that proxying reduces your options. Even in the non-SRLG 
case it is true that if it were the case that a repair was impossible to a 
proxy it may still be possible for all destinations except that proxy. 
However, our view is that if the failure is not 100% repairable then it is 
irreparable, so rather than giving some destinations poorer service it 
would probably be better not to attempt repair at all for that link. Not 
that we have seen any such irreparable links in real networks, but that is 
the principle behind the proxying.

In the case of SRLG, this might translate to a case where it was necessary 
to use secondary repairs because a few destinations could not otherwise be 
repaired. What this would mean is that we might use a secondary repair for 
some destinations which (if we had done the whole calculation per 
destination) could ave been repaired via a single primary repair. This is 
also true of node failures (which are of course SRLGs in disguse).

Mike

---

From: Naiming Shen <[email-masked]>
Date: Tue, 23 Nov 2004 10:26:12 -0800

Another issue I have not seen any discussion on the
list is how fast the "FRR" can be accomplished on the
node for a IPFRR scheme.

For MPLS LSPs and it's FRR, a node may only have hundreds
or thousands of LSPs, it's not common to see 10s of
thousands LSPs using the same interface on a node.

For IPFRR, we need to consider maybe half a million routes
pointing to the same nexthop, it's very different in
scaling comparing to MPLS LSPs.

if a scheme requires to change each one of the nexthop
in response to link/node failure for a million routes, it
may not be 'fast' enough to be considered as fast-reroute.

Just want to mention that for NFRR, since it's only dealing
with a known nexthop, regardless of the number of routes
using this nexthop, it only needs to have one operation
to redirect to an alternative nexthop. It works the
same if there is only a hundred routes pointing to it, or
one million routes pointing to it.

For non-nexthop based IPFRR schemes, another level of
redirection can be introduced, but this also will increase
the complexity of the scheme for implementation. When
anyone wants to compare comlexity of mechanisms, we
need to keep this in mind.

thanks,
- Naiming

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 23 Nov 2004 13:48:12 -0500

Mike,

I don't understand the algorithm(s?) that you two are discussing.

In MPLS/TE you simply remove all links from the topology that share a
common SRLG or for some types of SRLG don't remove the links but
weight those links to encourage avoiding them.  Then run the CSPF.

An interesting problem with IP FRR and SRLG is that an SRLG means that
the links *might* go down concurrently.  It does not indicate that the
links *will* go down concurrently.  If two links share a common
resource they will go down simulaneously if failure of that resource
is the cause of the outage.  If you use the above approach and the
failure is due to some other cause, normal hop by hop forwarding could
cause a loop.

MPLS/TE FRR does not suffer from this problem because tunnels are used
in the backup that terminate at the egress where the path is dictated
by the ingress or the PLR (point of local repair).  Therefore MPLS/TE
FRR can select a path which avoids all links that could potentially
fail without being concerned that a routing loop could form due to an
inconsistent decision.

Alia has addressed the problem of local SRLG and has provided a clear
enough description of how that works.  There is some question whether
the more general SRLG problem can be adequately addressed because of
the above problem.

The algorithm description above doesn't seem complete and therefore
doesn't make sense to me but that might be becuase the description was
sketchy or it might be just because I'm being dense.

For example:

      . . . . X
     .        .
    a --- b   .
    |      \ .
    |       e
    |      /
    c --- d

A is trying to get to e and looking to protect against failure of a-b
but a-b and d-e share a common fiber (a, c, d may be near each other
geographicly and b, e may be near each other).  A needs to use a long
path via X.  I don't see how this "far side of the SRLG" idea fits
into an algorithm that solves this problem.  Note that U-turn doesn't
address this since d-e is not local to A.  The SRLG could also be a-b
and c-d in a slightly different example.

The physical fiber involved in the SRLGs may look more like this
(where the = are two lambdas on the same segment of fiber).

      ..X1..X2..Xn-1..      ..Xn..
     /                \    /     .
    a ----=========----====---b  Xn+1
     \   /         \           \ .
       c             --- d ----- e 

Even more interesting is the case were a-b shares one SRLG with a..x
and a-b shares another SRLG with a-c.  In MPLS TE, the primary path
can be changed to a-c-d-e so that the backup path a..x..e could be
used and the primary and backup paths did not share any SRLG.  This is
generally done only with primary and standby (backup from ingress to
egress) or ingress as a PLR in FRR since the ingress and not
the PLR determines the primary path.  It would be difficult for the
ingress to select a primary path that assures that a feasible backup
is available at any PLR.

For example:

        . . . . X
       .        .
    - a --- b   .
  /   |      \ .
 z    |       e
  \   |      /
    - c --- d

If Z is now the ingress, Z is unlikely to consider whether A has a
viable repair path when selecting the path to E.  Z would likely pick
the path z-a-b-e if the path z-c-d-e was a viable packup for failure
of z-a and then A would have no way to create a viable backup.  A
better example of this is where one SRLG is a-b and a.x and another
SRLG is a-b and a-c and the third is a-b and z-a.  The path z-a-b-e
and z-c-d-e are fully disjoint but A has no backup path.  OTOH if A
picked a primary path of z-c-d-e, Z, C and D all have viable backups
when acting as the PLR.

Note: I'm using . to mean multiple hops and - to mean one hop, but it
only matters in the a.x.e case since there I just want to indicate
higher cost.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 23 Nov 2004 14:04:30 -0500

> thousands LSPs using the same interface on a node.

There might be a larger number of LDP and/or VPN labels, but not
MPLS/TE LSPs.  So I agree completely.  Thousands is rare.  I've not
yet heard of anyone actually getting to 10,000.

> scaling comparing to MPLS LSPs.

That is done with a two stage forwarding.  IPFRR protects IGP
destinations and routes are mapped into IGP destinations.  The IGP
destinations are protected, then switched over first, then any BGP
routes that map into different IGP routes as a result of the topology
change see a route change.  Its faster and avoids the problem of
needing to jam a few hundred thousand entries into hardware to get the
fast recovery to work.

> may not be 'fast' enough to be considered as fast-reroute.

Very true.

> one million routes pointing to it.

How do you do node protection in this case:

     b--d--g,h,i...
    /   |
   a -- e
    \   |
     c--f--q,r,s...

If the best path from a to d and from a to f used a-e, what is your
backup path for a-e?

I also don't think NFRR covers SRLG in that case.

> need to keep this in mind.

Reducing complexity is a worthy goal, but you know what Einstein said
about as simple as possible but no simpler.  If it no longer works
we've gone to a solution which is too simple.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Nov 2004 14:08:51 -0500

Hi Naiming,

>thousands LSPs using the same interface on a node.

Each of those LSPs requires separate forwarding state, both for primary and 
for backup, because there is a different label or label stack involved.

For good scaling, it is desirable to be able to fail-over from primary to 
backup based on a next-hop event regardless of the number of LSPs.

>scaling comparing to MPLS LSPs.

A difference is that most of those routes can use the same forwarding state 
as that associated with one or more IGP nodes.

Thus, while there may be more routes than LSPs, there is indirection possible.
This is more clearly seen with LDP, where that vast number of routes can be 
and generally is reduced down to a small number of FECs.

>may not be 'fast' enough to be considered as fast-reroute.

Absolutely.  Implementation does matter.  You can do TE-FRR way too slow also.

>one million routes pointing to it.

This seems to me to be missing several points.

First, if only link protection is desired, then all routes that are using a 
particular link can be given the same alternate; this may mean that some 
destinations aren't protected when they could have been, but it's a first 
pass simplification.  This is the case regardless of whether NFRR is used 
or some other mechanism; it is simply a side-effect of the far end of the 
link proxying for all destinations reached through that link.

Second, if node protection is desired, then it is necessary, in NFRR as in 
any of the tunneling schemes, to track the next-next-hop for each route or 
IGP destination.  In that case, you need to organize indirection of routes 
to primary & alternate based upon the next-next-hop.

NFRR provides no added benefit that I can see here.  If one has the ability 
to add that extra level of indirecton (desirable anyway for fast IGP 
convergence), then that level can be added in to handle any of these IPFRR 
schemes.

>need to keep this in mind.

As I said above, I don't think that a non-nexthop based IPFRR scheme adds 
another level of indirection.  It is the same level that is necessary for 
node protection.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Nov 2004 15:37:10 -0500

>failure is due to some other cause, normal hop by hop forwarding could

The big difference is that with IPFRR, one can't prune the topology, b/c 
the topology is what the other nodes will obey.  Instead, I think that one 
tracks the SRLGs that are traversed.  Then a path can be discarded if a 
common SRLG is traversed.

It isn't desirable to go to a node that would also be using an alternate, 
b/c then you can get looping alternates or need to consider what alternate 
that node would have selected.  It's much better to go to a node whose 
primary path doesn't traverse the common SRLG.

If no such path is available, then one could give weights to SRLGs and 
select an alternate appropriately.

>the more general SRLG problem can be adequately addressed because of

I think that it can; it requires tracking SRLGs, which is unfortunate.

>and c-d in a slightly different example.

One could address this with loop-free or U-turn, depending on tracking 
SRLGs traversed by each neighbor or neighbor's neighbor to the destination.

Alia

---

From: Naiming Shen <[email-masked]>
Date: Tue, 23 Nov 2004 21:19:11 -0800

> needing to jam a few hundred thousand entries into hardware to get the

That's cool. I guess my concern was that not all the forwarding
architecture has the indirect adjacency forwarding capability
due to hardware or performance issues.

> If the best path from a to d and from a to f used a-e, what is your

You meant when "e" is gone? wouldn't 'a' use a-b-d and a-c-f out ?

> I also don't think NFRR covers SRLG in that case.

which links are related in this case?

> we've gone to a solution which is too simple.

Agreed, if you can approve that something is "as simple as possible";-)

thanks.
- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Tue, 23 Nov 2004 23:02:16 -0800

Hi Alia,

Alia Atlas wrote:
> Each of those LSPs requires separate forwarding state, both for primary 
> and for backup, because there is a different label or label stack involved.
> 
> For good scaling, it is desirable to be able to fail-over from primary 
> to backup based on a next-hop event regardless of the number of LSPs.

yes, it's regardless of the number of LSPs for each LSP switch-over,
but the total switch-over time is linear to the number of LSPs affected.

> A difference is that most of those routes can use the same forwarding 
> state as that associated with one or more IGP nodes.
> 

yes, indirection makes it scalable. but a hardware design or an
existing forwarding engine may not want to do indirection due to
extra processing at forwarding time.

> This is more clearly seen with LDP, where that vast number of routes can 
> be and generally is reduced down to a small number of FECs.
> 
> First, if only link protection is desired, then all routes that are 
> using a particular link can be given the same alternate; this may mean 
> that some destinations aren't protected when they could have been, but 
> it's a first pass simplification.  This is the case regardless of 
> whether NFRR is used or some other mechanism; it is simply a side-effect 
> of the far end of the link proxying for all destinations reached through 
> that link.
> 

yes, I guess my comment was more related to the link-protection case,
which is simple enough and most vendors will just do it.

> Second, if node protection is desired, then it is necessary, in NFRR as 
> in any of the tunneling schemes, to track the next-next-hop for each 
> route or IGP destination.  In that case, you need to organize 
> indirection of routes to primary & alternate based upon the next-next-hop.
> 
> NFRR provides no added benefit that I can see here.  If one has the 
> ability to add that extra level of indirecton (desirable anyway for fast 
> IGP convergence), then that level can be added in to handle any of these 
> IPFRR schemes.

For the hardware can do indirection of adjacencies, you are right,
that's not a big problem. But even that, NFRR is only concerned about
a couple of next-nexthop adjacencies and the traffic is for sure
being switched over to the next-nexthop nodes. For non-nexthop schemes,
I guess one needs to worry about BGP nexthops which are IGP nodes,
and next-nexthops of those IGP routes, so there is more complexities
to figure out those alternative indirections. And in the case of
inter-area node-protection of ABR router, this will be rather tricky.

thanks.
- Naiming

> As I said above, I don't think that a non-nexthop based IPFRR scheme 
> adds another level of indirection.  It is the same level that is 
> necessary for node protection.
> 
> Alia
> 
> 
>

---

From: mike shand <[email-masked]>
Date: Wed, 24 Nov 2004 08:17:52 +0000

Curtis,
         See inline.

         Mike

At 13:48 23/11/2004 -0500, Curtis Villamizar wrote:

>links *will* go down concurrently.

True, but in IPFRR we have no knowledge of which of these has happened so 
we have to assume the worst case. The whole point is that we install the 
repair before the information about the failure has had time to propagate. 
I suppose if we were prepared to lower our sights somewhat, and have a 
mechanism which operated at the limit of propagation time we COUL wait a 
while after detecting a failure to see if we saw any LSPs from anywhere 
else, and then act accordingly. We already have this concept for loop 
prevention, but that is somewhat different since in that case we have the 
luxury of knowing that any failure has already been repaired, so we are not 
loosing traffic while we are waiting.

>If two links share a common

I don't see why that would be true. Remember that in that case of the 
tunnels appraoch, the whole essense of the approach is that the paths are 
unaffected by the failures. i.e. Fspace (aka Pspace) is the set of nodes 
which can be reached from S by paths which are unaffected by the failure, 
and Gspace (aka Qspace) is the set of nodes which can reach the "target" 
(proxy for destination) by paths which are unaffacted by the failure. Hence 
the entire path tunneled to F/G and released to the destination is 
guaranteed to be unaffected by the failure.

>into an algorithm that solves this problem.

Ok from A's perspective, run a normal SPF and you find that B and D are the 
far sides. No actually, assuming dashes are hops or something, then D is 
not reached via CD. So in this case you would find A's F-space with respect 
to AB and CD failure, and then computes B's G space with respect to AB and 
CD failure (by running a reverse SPF rooted at B and excising any sub-tree 
which traversed either AB or C. The resulting overlap between F sapce and 
Gspace would occur somewhere in the A....X....B brnach, and that is where 
the repair traffic for B,E and D would be sent.

 From C's perspective the situation is similar and again the repair point 
would be somewhere near X.

>  Note that U-turn doesn't

Yes this is the classic GMPLS case and there are well known algorithms for 
calculating link and or node diverse paths. To solve this it is necessary 
(as you point out) to move the primary path away from the normal shortest 
path in order to avoid blocking.

However, we do not have the luxury of this sort of thing in a pure IP 
network. The primary path is always the shortest path and there is nothing 
we can o about it.

Its a very different problem.

>viable repair path when selecting the path to E.

Z's primary path to E will be strictly the shortest path and hence in your 
example will be an ECMP via A and C. As before A's repair for the SRLG of 
AB,CD will be via X, and so will that of C. So if AB only has failed, 
traffic from Z to E will be split between ZAXE and ZCDE. But if AB and CD 
have failed it will be split between ZAXE and ZCZAXE (since C's shortest 
path to X is via Z. Note that this is NOT a loop, since the packet when it 
comes back through Z is encapped with a destination of X not E. This is 
ugly, but not disastrous.

>   Z would likely pick
>SRLG is a-b and a-c and the third is a-b and z-a.

This case is not very interesting from Z's perspective. IF it detected ZA 
had failed it would also have to assume that AB had failed, but it would do 
this anyway since it must assume that node A has failed.

But this does raise an interesting question. So far we (well at least I) 
have been thinking of SRLG in terms of a set of links failing. But we know 
already that we need to consider node failure as an SRLG consisting of all 
the links from a neighboring node, so if we see the link to our neighbor go 
down we must assume that the node itself has gone down. So does this mean 
that if we have a neighbor E, and SE is an SRLG with links XY and ST, the 
ACTUAL SRLG we have to consider is node E failure and links ST and XY failure?

>   The path z-a-b-e

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Nov 2004 09:46:06 -0500

> due to hardware or performance issues.

This is true.  The performance issues of older hardware from specific
vendors is out of scope for a discussion of the protocols although it
is a practical consideration for providers that have certain older
hardware.  I don't pretend to know which hardware can and can't do
this, but I do think its quite a lot of it.

OTOH if the goal of the provider is to support VOIP and the gateways
that need the fast restoration are in the IGP it might be good enough
to support fast restoration of the IGP only and let BGP catch up at
its own slower pace.  Again this is a practical consideration for the
operator and out of scope for the protocol specs themselves.

> You meant when "e" is gone? wouldn't 'a' use a-b-d and a-c-f out ?

Yes.  For the node disjoint case.

> which links are related in this case?

Node disjoint.

> Agreed, if you can approve that something is "as simple as possible";-)

Its the other way around.  You have to prove that something works.  If
it works use it unless you can find something simpler that also works.
When considering an alternative that seems simpler you have to prove
that it really does work.  If you are having a lot of trouble proving
that it will work or even coming up with a convincing argument that it
should work, then you might want to stick with what you know works.

Anyway the point of the discussion we are having is to better
understand any limitations to IP FRR.  If it usually works except when
X, we understand what X is.  So far X seems to include SRLG and in
some techniques asymetric costs, and in all techniques under
discussion full coverage for all topologies, and maybe other things.
There is no consensus within the WG that any of this is a reason not
to continue, but we should discuss and known limitations and
acknowledge them in the framework document or individual documents.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Nov 2004 16:24:20 -0500

>          Mike

You misunderstood part of the message because I was elaborating on a
limitation of MPLS/TE in the last part of this.  Sorry for the
confusion.  I made a point about MPSL FRR and then followed with the
example.  That was the final example with a Z in the topology.

You did acknowledge another limitation of all IP FRR approaches that
hadn't been explicitly mentioned previously.  See inline.

There were a few points that maybe I didn't make clearly so I'll try
to clarify.

Part of the problem is you seem to be replying to every post as if all
the comments are directed only at your approach.

See comments inline.

Curtis

> guaranteed to be unaffected by the failure.

The first part of your tunneling (since it isn't explicit route
tunneling) relies on IP forwarding.  Plain IP with a multiple link
failure can have loops form even with symetric routes due to some
nodes reacting to the failure earlier than others.

> the repair traffic for B,E and D would be sent.

You didn't read down to the line that said:

  Note: I'm using . to mean multiple hops and - to mean one hop, but
  it only matters in the a.x.e case since there I just want to
  indicate higher cost.

Any path by way of X is a high cost path.  The point was that without
considering SRLG in this case IPFRR would loop.  Of course you had to
read the whole email message before replying so my fault for putting
that paragraph at the bottom of the message.  Common notation is to
use ... to mean a long (high cost) path.

A-X and A-B share an SRLG.  When a failure occurs at A-B, A does not
know if A-B alone failed, if A-B and C-D have both failed or if A-B
and A..X have failed (non-local failure).  In IP FRR if the failure at
A-B directs traffic toward X the traffic would never reach X.  There
may be a repair at that point in IP FRR that would send the traffic
back around the other way, encapsulating a second time but if the
lowest cost path to X required it to go by way of e (best path from d
to X is by way of c) then there would be a loop.

> Its a very different problem.

This is a type of problem that occur in the real world.  It is not
addressed by any of the IP FRR solutions but is addressed by MPLS FRR.
This is just something that the framework document should mention.

The remainder of this message starts out but saying "In MPLS TE,
...".  Somehow you seemed to lose the fact that I was describing a
limitation of MPLS FRR below.

> ugly, but not disastrous.

In MPLS TE A would simply have no backup that didn't violate an SRLG
and the local-protect-available bit would not be set notifying the
ingress of the problem.  Given current algorithms the ingress would
not know what to do about it (the CSPF would still show z-a-b-e as the
best path).  When this occurs the only way to solve it would be for Z
to do an SPF rooted at each node on the path that could not get
local-protect-available and figure out which links needed to be
avoided for that reason.  

> this anyway since it must assume that node A has failed.

Since the example was illustrating a limitation of MPLS TE, it is
interesting from Z's perspective.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 24 Nov 2004 16:40:40 -0500

Curtis,

>nodes reacting to the failure earlier than others.

I think that Mike (and I) are using an implicit assumption.  There are two 
potential causes for loops.  The first case is when the use of the 
alternates themselves cause loops.  This could occur if, as described in 
the LFA draft, two routers both have link-protecting LFAs that point at 
each other and the node fails, so that both those routers invoke their 
alternates.  I believe that Mike was arguing that an alternate could be 
found which prepares for an SRLG failure, and therefore one wouldn't have 
that type of loops.

The second potential cause for loops would be due to the different new FIB 
installation times of routers in the network.  That is being addressed 
separately in the micro-loop prevention work.  Take a look at 
http://www.psg.com/~zinin/ietf/rtgwg/IETF61-rtgwg-uloop-prev.ppt for the 
presentation that Mike, Stewart and I did at the last IETF.

Alia

---

From: Naiming Shen <[email-masked]>
Date: Wed, 24 Nov 2004 14:22:36 -0800

> this, but I do think its quite a lot of it.

You might be surprised on this, since it's not just with the legacy
hardware pieces, even the new ones, with increasing demand on services,
features, and marketing requirement for small packet in line rate,
this is one place performance can be boosted. Of course, this has
"nothing" to do with the protocol design ;-)

Cheers.
- Naiming

---

From: Alia Atlas <[email-masked]>
Date: Wed, 24 Nov 2004 17:42:44 -0500

>"nothing" to do with the protocol design ;-)

Indirection is powerful, but can come at a performance cost.  It doesn't 
have to; the hardware may need to fetch a memory location anyway, for 
instance, and this could just have the same memory location used multiple 
places.  The side-benefit is that it can save substantially on FIB memory.

As you say, nothing to do with protocol design, except that the protocol 
hierarchy makes it useful :-)

Alia

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Nov 2004 18:56:18 -0500

> "nothing" to do with the protocol design ;-)

Or I might not be surprised and I was being generous.

Either that or I was trying to imply that some vendors are currently
making legacy hardware.  But that wasn't the case.  :-)

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Nov 2004 00:14:07 -0500

Mike,

It sounds like you're doing per-destination alternate assignment and the 
proxying is just limiting the set of candidate alternates then.

I am a bit surprised by the numbers you have for just LFA plus tunnel 
protection.  They seem very comparable to what I'm seeing with the U-turn 
alternates.  I thought that the added degree of freedom with the tunnel 
might have made a noticeable difference.  I know you've only simulated the 
U-turn alternates with link protection, but since you've got these 
topologies :-), do you have numbers for comparison there?

The directed forwarding gets you up to 3 routers away and that adds enough 
to cover most cases.

I've been thinking about the cascaded U-turns which could offer a similar 
reach.  It's pretty straightforward to go upstream 2 hops instead of 1; 
there's a need to do additional computation for it.  One can combine the 
computation, but at the cost of greater pessimism (likelihood of ignoring 
an alternate that did exist b/c it might not offer the desired 
protection).  If combining the computation is worth the pessimism 
(something I'm still investigating), then it is possible to go an arbitrary 
number of hops upstream u-turning.

Alia

At 11:26 AM 11/23/2004, mike shand wrote:
>>The percentage that is missing is then those that require a single 
>>primary tunnel for repair?  These are the number for repair for node failure?
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Nov 2004 00:27:57 -0500

Hi Mike,

>find which is the far side.

And store all of them and use them as proxies?  What about SRLG links in 
series?  I guess you'd need to trim the trees as well.

>the principle behind the proxying.

I think I disagree with that argument.  Consider a case where one wants to 
protect VPN traffic, but not necessarily all traffic.  In that case, as 
long as all sources to the set of relevant PE routers are protected, it 
doesn't matter (as much) that the other destinations aren't 
protected.  There can definitely be cases where one or more particular 
destination nodes are of the most importance; think of protecting a 
valuable video broadcast stream, for instance.

It does seem to me that the proxying at just a next-next-hop won't work 
well for SRLGs.  Doing the proxying at the end of each link of the SRLG and 
then deciding which to use for each destination might.

>also true of node failures (which are of course SRLGs in disguse).

Where would you do the secondary repair to?  It couldn't be the 
next-next-hop normally used, because that path is at risk of failing due to 
the same SRLG (for some sub-set of the destinations).  Also, on the 
secondary repairs, didn't you have some concerns about the computational 
feasibility of them?

Node failures aren't general SRLGs in disguise; they're local SRLGs in 
disguise and that makes all the difference.  The main difference is that 
distance comparisons don't help at all for SRLGs.  The only way to tell 
that a path traverses an SRLG is to track it!  SRLGs are random attributes 
of a link.  For node failures or local SRLGs, one can simply avoid the 
relevant node.  If you've got a local SRLG and no node-protection, then 
it's back to tracking, but a hopefully more limited set of SRLGs.

Do you know a cleaner way to handle them?  We can't prune them beforehand 
(b/c the routers in the network consider them for their SPFs) and one can't 
prune them during the SPF, b/c the path across a particular SRLG isn't 
known to be the shortest.  One could poison the path at a certain distance, 
but the poisoning would be SRLG dependent.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Nov 2004 00:35:27 -0500

Hi Naiming,

>but the total switch-over time is linear to the number of LSPs affected.

The total switch-over time doesn't have to be linear with the number of 
LSPs affected.  It's certainly possible to design a fast path where this 
isn't the case.  I even think it is highly desirable (seen through the 
focused glare of fast-reroute technologies).

>extra processing at forwarding time.

As I mentioned elsewhere, this is very hardware dependent.  It doesn't have 
to be extra processing and it saves on FIB memory.

>>route or IGP destination.  In that case, you need to organize indirection 
>>of routes to primary & alternate based upon the next-next-hop.

These are the multi-homed prefix cases.  Mike and Stewart have a good 
discussion of them (even slanted towards tunnels oddly enough ;-) in their 
draft.  It's a bit of added complexity, but not too bad.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Nov 2004 00:57:56 -0500

At 03:17 AM 11/24/2004, mike shand wrote:
>the links from a neighboring node, so if we see the link to our neighbor 
>go down we must assume that the node itself has gone down. So does this 
>mean that if we have a neighbor E, and SE is an SRLG with links XY and ST, 
>the ACTUAL SRLG we have to consider is node E failure and links ST and XY 
>failure?

I think that the ideal is to have an alternate that provides link, node and 
SRLG protection.  Each protection set is a different check.  If such an 
alternate doesn't exist, then it's just a question of prioritization.  We 
have the same problem between link and node protection.

Alia

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 11:23:47 +0000

> I think I disagree with that argument.  Consider a case where one wants 
> to protect VPN traffic, but not necessarily all traffic.  In that case, 
> as long as all sources to the set of relevant PE routers are protected, 
> it doesn't matter (as much) that the other destinations aren't 

What we have not discussed, but which applies in this case, is 
applying LF to a subset of the prefixes.

What Mike and I have always been alarmed at is the thought that in
protecting some subset of the prefixes, we damage - perhaps quite 
badly- the service to other prefixes unless we have 100% coverage.

Now what we could perhaps to is to run LF on just the prefixes that
we can protect. So if we knew that we had 100% protection on say
VPN and PWs. We could run controlled convergence on the adresses
of those endpoint address and run uncontrolled on the rest.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 11:47:32 +0000

> It does not have to be "MPLS" if you consider the IP TE mechanism though

Can you summarise how you steer these packets through an IP network?

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 11:54:00 +0000

> offering multicast over IP with no TE or FRR.

No, but video providers doing TV over IP use multicast, and I would
have thought that they would have been interested in a fast-reroute
capability that supported multicast. However there are simplications
that one might be able to apply to such applications.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 11:44:01 +0000

> to egress.  So the worst case is a slow restoration but not a loop.

How is this achieved? Presumably by excluding from the set of packets
that can be repaired and packet with a label that indicates that it is
part of a repair tunnel.

If we were to always tunnel to the other side of the failure we
could do the same sort of thing in IPFRR, but prefer to sent
the packets native. We could however mark the packet as being
repaired somehow (TOS bit perhaps) and then refuse to re-repair it.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 10:49:53 +0000

> to use IP FRR to speak up.

I agree. The only way that we will ever resolve the issues that arise
from the constraints that are intrinsic to each method is via a set of
agree requirements. Such requirements need to address the needs of 
both the SP market and the Enterprise market.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 10:14:02 +0000

>> feasible the 2 hop algoritm is.

The use of the word hop may be confusing here. This is two stage 
rather than two hop, and there may be multiple hops per stage.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 10:10:34 +0000

Alia Atlas wrote:
> destinations.  

This was to reduce the number of SPFs that we ran. If we relax that 
constaint we that look at alternatives.

> It is possible that the path from the next-next-hop to a 

Strictly because there is no G such that the path from S to G and the 
path from G to Si does not contain an SRLG member, even via a 
secondary repair.

> If we were willing to accept an SPF per node in the topology, then 
> looking at SRLGs would be a lot simpler!

Agreed. Indeed I suspect a number of new approaches then become feasible.

> 
> If I were even willing to accept an SPF per neighbors' neighbor, it 
> would be completely clear how to do SRLGs for U-turn alternates.

I can see how with one SPF per node you can increase the reach of
U-turn, but surely to do SRLG you need to carry some vector in the
packet to steer it at critical places?

> 
> The computational complexity for MPLS/TE can be quite large, depending 
> on the number of tunnels to be considered.  Sure, one can use techniques 
> to minimize the impact, but it is there.
> 
> I'd say it's clear that for IP FRR, there's a desire to have 
> substantially fewer SPFs than 1 per node.

That is a desire, although I have some personal doubts at the validity 
of that constraint. Remember that when we designed link state
protocols we were using CPUs that were three orders of magnitude 
slower than those that we use today.

> 
> There is the basic fact that without source-based routing, it might not 
> be possible to find an alternate.
> 
>> the problem should at least be acknowledged in the documents.  

We can certainly do much better than the current document implies and
any description should include some sort of applicability statement 
that describes the constraints.

>> If SRLG

Agreed.

> neighbor, and decide whether to use a loop-free neighbor based on 
> whether the SRLGs of concern are passed.

We can do the same for tunnels, and you can do the same for U-turn.
The general approach is that you must check that you do not go over
an SRLG member during the period that you control the packet, and
then make sure that it does not go over one after it is released. The
issue is what to you do if it does.

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Fri, 26 Nov 2004 11:35:53 -0500

>repaired somehow (TOS bit perhaps) and then refuse to re-repair it.

I think that if the point where a repaired packet re-joins the SPT is 
always a downstream path, then we could have the same 
property.  Unfortunately that does limit coverage a bit.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 26 Nov 2004 11:45:26 -0500

>packet to steer it at critical places?

There's no need for a vector in the packet.  There needs to be a path from 
S to the node from which the SPT will be followed.  The path from that node 
on the SPT needs to avoid the SRLG.

Whether one can find this depends on the topology.

>That is a desire, although I have some personal doubts at the validity of 
>that constraint. Remember that when we designed link state
>protocols we were using CPUs that were three orders of magnitude slower 
>than those that we use today.

Which means we can do a handful of SPFs, not 100s or 1000s.

>issue is what to you do if it does.

Give up on that as an alternate and hunt for another one?

Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 26 Nov 2004 11:48:08 -0500

At 06:23 AM 11/26/2004, Stewart Bryant wrote:
>What we have not discussed, but which applies in this case, is applying LF 
>to a subset of the prefixes.

The importance of the micro-loop prevention depends on the duration of the 
possible micro-loops.

>protecting some subset of the prefixes, we damage - perhaps quite badly- 
>the service to other prefixes unless we have 100% coverage.

The micro-loop prevention can't make the service to other prefixes 
substantially worse.

>of those endpoint address and run uncontrolled on the rest.

Right, but how do we communicate the prefixes that are protected (or 
unprotected) in a reasonable fashion?

Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Nov 2004 12:01:18 -0500

There is a subtlety that I am missing in the phrase 100% protection for 
some traffic".
Do you mean that we should be careful not to redirect (LF, U-turn, or 
tunnel) traffic which will not be properly protected by the technique, and 
use the tool for traffic for which we can know it will work?

I had thought that when we said 100% protection we were talking about 
proptecting all traffic against all possible failures.  Maybe I misunderstood.

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 17:30:08 +0000

Alia Atlas wrote:

> always a downstream path, then we could have the same property.  
> Unfortunately that does limit coverage a bit.
> 

The assertion was that MPLS RSVP/TE FRR is unconditionally LF against
unexpeceted SRLG.

+---------------------------------+
|                                 |
A-----B--------C---------E--------F
                |
                D

AB breaks and unexpectedly FE breaks. What stops the loop?

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 17:54:10 +0000

> Which means we can do a handful of SPFs, not 100s or 1000s.

Sorry I don't follow. When LS protocols were introduced (say 1990)
we had processors that could do 1 mip doing everything. As I recall
speed doubles every 18mths, which I think is 2^(14*2/3) which is
over 500. So why can't we run order 500 SPFs? Where did all the 
performance go?

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 17:56:17 +0000

Alia Atlas wrote:

> There's no need for a vector in the packet.  There needs to be a path 
> from S to the node from which the SPT will be followed.  The path from 
> that node on the SPT needs to avoid the SRLG.
> 

I think that you are saying if we don't have the vector we can
look for a repair, but might not find one - depending on topology.
Whilst I am saying if you have a vector you can create one where
otherwise you mightnot find it. Is that right?

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 18:20:57 +0000

Alia Atlas wrote:

> The importance of the micro-loop prevention depends on the duration of 
> the possible micro-loops.

Yes, we agree on that.

> The micro-loop prevention can't make the service to other prefixes 

If a prefix is not repaired, it is black-holed until we reconverge.
All the LF approaches delay convergence, then those prefixes are
black-holed for longer.

> unprotected) in a reasonable fashion?

Surely the simplest approach is for the node that issues the LSP to
say "and by the way I am protecting the following IGP paths". That
would take about 1000 bits which is not unreasonable.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Nov 2004 18:30:35 +0000

Joel M. Halpern wrote:

> tunnel) traffic which will not be properly protected by the technique, 
> and use the tool for traffic for which we can know it will work?
> 

Mike and I wanted to do all src all dest repair for any failure.

Say you cannot do this, you have a problem. If you use uncontrolled
convergence then you damage the repairs, but you restore connectivity
to unrepaired prefixes ASAP.

If you use controlled convergence you protect the repairs, but you
blackhole the unrepaired prefixes whilst you converge - which takes time.

The suggestion below is to run controlled convergence on the prefixes
that are repaired and uncontrolled (faster) convergence on the rest.

Stewart

>>> I think I disagree with that argument.  Consider a case where one 
>>> wants to protect VPN traffic, but not necessarily all traffic.  In 
>>> that case, as long as all sources to the set of relevant PE routers 
>>> are protected, it doesn't matter (as much) that the other 
>>> destinations aren't protected.  There can definitely be cases where 
>>> one or more particular destination nodes are of the most importance; 
>>> think of protecting a valuable video broadcast stream, for instance.
>>
>>

---

From: Naiming Shen <[email-masked]>
Date: Mon, 29 Nov 2004 10:19:51 -0800

Hi Stewart,

> Can you summarise how you steer these packets through an IP network?

I did a presentation in San Diego on IP TE, and here is the updated
draft,

  http://www.ietf.org/internet-drafts/draft-shen-ip-te-rsp-03.txt

Cheers,
- Naiming