Document: draft-ietf-rtgwg-ipfrr-framework-11
Reviewer: Avshalom Houri
Review Date: 2009-09-04
IETF LC End Date: 2009-09-04
IESG Telechat date: (if known) - 

Summary: This document is nearly ready for publication as an  
informational RFC. There are a few issues that have to be resolved first. 

Major issues: 

Lines 716-718 - (Security Considerations) It may be reasonable that the framework does not introduce 
new security threats but it seems that there should be more explanations 
regarding security and possible security issues that may arise from fast reroute. 

   This framework document does not itself introduce any security 
   issues, but attention must be paid to the security implications of 
   any proposed solutions to the problem. 


Minor issues: 

It may be good to do some English editorial review on the document. 
Lines 151-155 - hard to understand the meaning of the paragraph. 
Probably the "This is" is redundant as in other definitions 

   LFA                 Loop Free Alternate.  This is a neighbor N, that 
                       is not a primary next-hop neighbor E, whose 
                       shortest path to the destination D does not go 
                       back through the router S. The neighbor N must 
                       meet the following condition:- 

Lines 178-182 - Sentence is too circular. 

   Loop Free Link Protecting Alternate 
                       This is a path via a Loop-Free Neighbor N_i which 
                       does not go through the particular link of S 
                       which is being protected to reach the destination 
                       D. 

Lines 184-188 - Sentence is too circular. 

   Loop Free Node-protecting Alternate 
                       This is a path via a Loop-Free Neighbor N_i which 
                       does not go through the particular primary 
                       neighbor of S which is being protected to reach 
                       the destination D. 

Lines 329-348 - It seems that what is meant is that two mechanisms should 
be used. 

   In order to achieve packet disruption times which are commensurate 
   with the failure detection times two factors must be considered:- 

   1.  The provision of a mechanism for the router(s) adjacent to the 
       failure to rapidly invoke a repair path, which is unaffected by 
       any subsequent re-convergence. 

   2.  In topologies that are susceptible to micro-loops, the provision 
       of a mechanism to prevent the effects of any micro-loops during 
       subsequent re-convergence. 

Lines 530-531 - The "Any figures" sentence should be in the beginning of the document. 

   dependent on the detailed topology and metrics.  Any figures quoted 
   in this document are for illustrative purposes only. 

Nits/editorial comments: 

Lines 285-286 - put hello in as e.g. "hello" or Hello 

       layer, up to several tens of seconds when a routing protocol 
       hello is employed.  During this period packets will be 

Line 322-323: "this is as a result" - rephrase 

   When micro-loops occur, this is as a result of the different times at 
   which routers update their forwarding tables to reflect the failure. 

Line 599 - add (SRLG) after "Shared Risk Link Groups", since it is used later. 

   Shared Risk Link Groups are an example of multiple related failures,