On 30/01/2013 18:33, Acee Lindem wrote:
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.
AAH took a lot of thought, so we would rather not loose it, if it works
better I could reverse the order of the appendixes.
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.
The abstract now says
"This mechanism can be used in the case of non-urgent (management
action) link or node shutdowns and restarts or link metric changes."
3.1.1 says
"First consider the non-urgent failure of a link (i.e. where an operator
or a network management system (NMS) shuts down a link thereby removing
it from the currently active topology) or the increase of a link metric
by the operator or NMS ."
The point is of course that although a link is shut down rather than
failing, a remote node cannot distinguish the two cases.
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.
We use rSPT in here.
As you know we are looking for a formal definition.
I have put in Section 5
This computation required the introduction of the concept of a reverse
Shortest Path Tree (rSPT). The rSPT uses the cost towards the root
rather than from it and yields the best paths towards the root from
other nodes in the network
[I-D.draft-bryant-ipfrr-tunnels].
If there is a better ref we can swap in Auth48.
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.
Done (in section 2).
4. Make sure the hold down timer is defined precisely and
early in the document. Currently, this doesn't happen until section 8.2.
On first use it says:
If all events received within some hold-down period (the time that a
router waits to acquire a set of LSPs which should be processed together) h
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.
R is now removed.
As has been described, a single event such as the failure or restoration
of a single link, single router or a linecard may be notified to the
rest of the network as a set of individual link change events. It is
necessary to deduce from this collection of link state notifications the
type of event that has occurred in the network and hence the required
ordering.
When a link change event is received which impacts the receiving
router's FIB, the routers at the near and far end of the link are noted.
If all events received within some hold-down period (the time that a
router waits to acquire a set of LSPs which should be processed
together) have a single router in common, then it is assumed that the
change reflects an event (line-card or router change) concerning that
router.
In the case of a link change event, the router at the far end of the
link is deemed to be the common router.
All ordering computations are based on treating the common router as the
root for both link and node events.
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???
This is the case where you have an unused link (due to costs), i.e. a
link not on any shortest 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).
I have added "Inclusion or removal of link" to the information list.
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.
Yes.
I have changes this to AAH_Hold_down_timer expires
Pierre and Mike please check this.
Nits:
1. Abstract - replace "However mechanism" with "However the
mechanism". I chose singular since it is singular in the preceding text.
done
2. Introduction - replace "base (FIB)" with "bases (FIBs)" in
the first sentence.
Done
3. Page 5, replace "change order no" with "change order, no".
Done
4. Page 9, suggest adding "IGP " to "reverse connectivity check".
Done
5. Page 10, suggest using parenthesis rather than relying on
arithmetic precedence for equations, e.g., T0 + H + (rank * MAX_FIB)
Done
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.
I will deal - but given we are Europeans... :)
7. Section 8.1, the actions are formatting inconsistently. In
one case, as a paragraph and the other as a list.
Done
8. Page 19, replace "algorithms i.e." with
"algorithms, i.e.".
Done
9. Page 19 and Page 22, use of (PNSM) and (PN) is inconsistent.
Done
10. Page 23, Run-on sentence beginning "Manual configuration...".
Done
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.
I think I got them, but RFC Editor will get this
Thanks for the review
Stewart
Thanks,
Acee
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
