[Gen-art] Gen Art LC review of draft-ietf-rtgwg-ipfrr-framework-11

[Avshalom Houri <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 
Please resolve these comments along with any other Last Call comments 
you may receive. 
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,

--Avshalom