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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
