[Top] [All Lists]

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

 Subject: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09 Rüdiger A Martin 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, Rüdiger -- _______________________________________________________ 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] https://www1.ietf.org/mailman/listinfo/rtgwg ```
 Current Thread Comments on draft-ietf-rtgwg-ipfrr-spec-base-09, mike shand Comments on draft-ietf-rtgwg-ipfrr-spec-base-09, Rüdiger A Martin <= Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09, Rüdiger A Martin