[email protected]
[Top] [All Lists]

Comments on draft-ietf-rtgwg-ipfrr-spec-base-09

Subject: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09
From: Rüdiger A Martin
Date: Fri, 12 Oct 2007 17:09:13 +0200
Dear Alia, dear Alex,

we have taken a look at your document and would like to add a few comments to the discussion already going on:
- The concept of node protecting LFAs is first mentioned on page 6. The
definition and explanation follows later.
- There are several kinds of loop-free alternates. But the suggested
order of preference among those different LFAs does not become clear at
all in the draft. So there should be some paragraph where all possible
candidate types are listed and described with their pros and cons. That
description should include the protected failure types but also the
behavior in case of unprotected failures: e.g., I miss a clear statement
that downstream LFAs do not create any loops no matter what kind of
failures may happen. Based on this, a clear suggestion for an order of
preference can be given.
- Page 7: "Since the funcionality of link and node protecting LFAs is
greater than that of downstream paths, a router SHOULD select a link and
node protecting LFA over a downstream path." - That reads like
downstream paths are generally worse. But of course a downstream link-
and node-protecting LFA is better than a non-downstream link- and
node-protecting LFA. So this point is strongly related to the point
mentioned earlier concerning the order of preference.
- A few comments on the algorithm on page 16 (besides I agree with
Stewarts comments):
 * Step 10: This means, if the router prefers other primary next
hops, it prefers them no matter what kind of failures (links or nodes)
they protect. So this algorithm prefers a link-protecting primary over a
link- and node-protecting downstream LFA. (Depending on the order of the
candidates - see below.)
 * The output of the algorithm depends on the order of the
candidate next hops.
 1) Imagine that H_1 is a link-protecting primary next hop.
H_2 is a link- and node-protecting downstream LFA. Then H_1 will be
selected in the first iteration. During the second iteration, step 11
selects H2 instead.
 2) Now imagine H_1' = H_2 and H_2' = H_1. Then the first
iteration selects H_1'. However, the second iteration selects H_2' as
the candidate in step 10. So the final result is H1.
         I think this problem is due to the missing order of preference.

Besides we really appreciate this document and support the progression of the document after consideration of the comments from above. We think that Mike's idea to include explicitly that this may only provide a partial solution is worth considering. But maybe together with the statement that this is a really simple and easy to implement approach since it does not require any support (i.e. signalling) from other routers.
Best regards,


            Dipl.-Inform. Rüdiger Martin
Department of Distributed Systems (Informatik III)
Insitute of Computer Science, University of Würzburg
       Am Hubland, 97074 Würzburg, Germany
        [email protected]
             Tel: +49 931 888-6651
Fax: +49 931 888-6632

rtgwg mailing list
[email protected]

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