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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
