Subject: needed improvements to Remote LFA draft

From: Alia Atlas <[email-masked]>
Date: Sun, 12 Aug 2012 08:39:26 -0400

There are several improvements that I would like to see to
draft-ietf-rtgwg-remote-lfa-00.  I believe at least the first four are
necessary to improve the draft sufficiently given its status as
Standards Track.

First, if the intent is to restrict this mechanism to ONLY link
protection, that belongs at a minimum prominently in the abstract and
introduction.  It is currently first mentioned only in Section 3.

Second, the algorithm description Sec 4.2.1 and Sec 4.2.2 needs
significant expansion into a more formal algorithm description, such
as is in the LFA spec, RFC 5286.  A brief description of the
computational complexity would be useful, but the critical part is
having it specified clearly.

Third, in Sec 4.2.3, there is no preferred or even specified method
for selecting among the different PQ options that might be available.
 Such a method should be specified; as the draft says, there is an
advantage from the network management perspective to consistency.   It
is also required to have agreement on the output of analysis to
compare/contrast methods.

Fourth, one issue described in RFC 5286 is what happens when a worse
failure occurs than the LFA was computed to handle - i.e. if a node
failure happens instead of a link failure.  In that case, traffic
looping can occur.  With Remote LFA, I believe that the same issue can
exist - but made even worse because there is no effort to look for
node-protecting Remote LFAs.   This concern needs some description in
the draft.  Additionally, the equivalent of the Downstream Paths
condition should be specified, if possible, that allows such traffic
looping to be avoided.  Finally, since the argument for Remote LFA is
the improved coverage over LFAs, I would like to see the coverage
analysis based on simulation to show the coverage when the Downstream
Paths equivalent requirement is met vs. when it is relaxed (as
currently in the draft).

Fifth, for a better understanding of realistic behavior, I would like
to see the analysis extended to show the min, average, and max
coverage for the 11 specified topologies after each single failure has
occurred in the topology.  (Of course, the computation should
recognize that protecting cut-links isn't feasible and not include
those failures.)

While I recognize that link failures are significantly more common
than node failures, I believe that fast-reroute techniques should be
able to cover node failures as well.  Technically, I think that Remote
LFA can, of course, be extended to provide node coverage - at the cost
of computing a reverse-SPF from each next-next-hop of the computing
router.   As I said early, at a minimum, the abstract and introduction
need to clearly specify that Remote LFA only provides link protection
and the traffic looping concerns need to be addressed.

Since this is now a working group draft, it would be good to see
progress and discussion on the draft.

Regards,
Alia

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 12 Aug 2012 16:54:08 -0400

Hi,

I agree with Alia's analysis of the current state of the draft.
I'd propose that someone, perhaps Clarence re-runs RFC6571 to include rLFA.

Regards,
Jeff

On Aug 12, 2012, at 5:39, "Alia Atlas" <[email-masked]> wrote:

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