Subject: [RTG-DIR] Routing Directorate Review of "Framework for Loop-free convergence using oFIB"

From: Acee Lindem <[email-masked]>
Date: Wed, 30 Jan 2013 18:33:54 +0000

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

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 31 Jan 2013 19:47:49 +0000

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.
> 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 
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

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html