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

[Acee Lindem <[e-mail]>]

Hi Stewart,
I'm looking at the -09 version. I'm happy with it. I only have one comment that I think could be a further improvement - see #1 below. 
 
On Jan 31, 2013, at 2:47 PM, Stewart Bryant wrote:

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

Ok - it does take a lot of effort to understand the AAH state machines but since it is in an appendix, the reader can choose to skip it. 

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

Ok. For both 3.1.1 and 3.1.2, you may also want to point out the use case of reconvergence of IPFRR repaired path. 

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

Ok. I think this will suffice for anyone who has been remotely following the IPFRR discussion. 

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

Right. I see that now. 

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

Good. 

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

That would make sense for a link failure. For a node failure, it is harder to visualize such a topology. 

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

Explicit specification works as well. 

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

Great. 

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

I figured that. ;^)  You did miss one: 

A.3.2.  Per Neighbor State Machine

> 
>>       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,
Acee 



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