Routing Directorate Review of "Framework for Loop-free convergence using oFIB"

[Acee Lindem <[e-mail]>]

Authors, et al,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-rtgwg-ipfrr-ordered-fib-08
Reviewer: Acee Lindem
Review Date: January 30, 2013
IETF LC End Date: January 31, 2013
Intended Status: informational

Summary:  This document is basically ready for publication, but has clarification that should be considered prior to publication.

Comments: The document accomplishes what it sets out to achieve in documenting the ordered FIB mechanism for avoidance of transient loops. While Appendix B is useful, I think the document would be better without Appendix A. Of course, this is just my opinion.

Major Issues: None

Minor Issues:
                           1. The document could benefit for a precise definition of a "non-urgent topology change". From what I gathered, this is any change that can be deferred during the ordered FIB delay.
                           2. Similarly, the document could benefit from a precise definition of the "rSPF". I checked RFC 5715 and it is not defined there either. I believe our discussions indicate that this is simply an SPF where the shortest path back to us is used as the cost. For example, for the first pass, the SPF would use our neighbor's link cost rather than our own.
                           3. It would be good to state early on that the current oFIB mechanism is limited to a single link or node failure and that multiple unrelated failures result in reversion to normal FIB convergence.
                           4. Make sure the hold down timer is defined precisely and early in the document. Currently, this doesn't happen until section 8.2.
                           5. Upon the initial reading, one may think there is some correspondence between the Router (R) in sections 4 and the Router (R) in section 5. Can this be clearer? Perhaps, (R) is not needed in section 4 since in all other sections, it refers to the computing router.
                           6. In section 5, I have trouble envisioning a case where a router would not be in an pre or post failure SPT. I guess if it had no loopbacks and only unnumbered interfaces or only interfaces to broadcast links offering a longer path???
                           7. In section 6.2, it would be instructive to say that a Link Down condition is represented by an infinite metric (or otherwise cover this condition).
                           8. In section 8.5, I believe this a different hold down timer than the one used to group LSPs related to the same failure.

Nits:

                     1. Abstract - replace "However mechanism" with "However the mechanism". I chose singular since it is singular in the preceding text.
                     2. Introduction - replace "base (FIB)" with "bases (FIBs)" in the first sentence.
                     3. Page 5, replace "change order no" with "change order, no".
                     4. Page 9, suggest adding "IGP " to "reverse connectivity check".
                     5. Page 10, suggest using parenthesis rather than relying on arithmetic precedence for equations, e.g., T0 + H + (rank * MAX_FIB)
                     6. There is a mixture of "neighbor" and "neighbour" in the document. Of course, I prefer the US English to UK English since this is what all the OSPF RFCs use.
                     7. Section 8.1, the actions are formatting inconsistently. In one case, as a paragraph and the other as a list.
                     8. Page 19, replace "algorithms i.e." with "algorithms, i.e.".
                     9. Page 19 and Page 22, use of (PNSM) and (PN) is inconsistent.
                  10. Page 23, Run-on sentence beginning "Manual configuration...".
                  11. There some instances where the opening clause for a sentence is preceded with a comma and some where it is not. I prefer the former. For example, section 4.2 appears to be written in a different style with missing punctuation.


Thanks,
Acee