Hi!
After a long wait, I finally got to this..
I do have some comments (minor and nits) that I would like addressed. As you
look at these I will get the write up ready to send to the IESG — you can
either address my comments now/before the IESG gets the publication request or
with any comments that come from them.
Thanks!
Alvaro.
Minor Issues
1. 4.2.1.3 states that "In Figure 1 the intersection of the E's Q-space with
S's P-space defines the set of viable repair tunnel end-points. . .there is no
common node and hence no viable repair tunnel end-point." The immediately
following section (4.2.2) starts with "The mechanisms described above will
identify all the possible repair tunnel end points that can be used to protect
a particular link." So..you're saying that there are no viable end-points
(which is technically true because you're using the P-space)..and then you say
that you figured out all the possible repair points, which is obviously not
true because in the previous section you didn't mention the union of the
Q-space and the extended-P-space. All this is to say that a reader may be
confused — adding mention of the extended p-space in 4.2.1.3 should clear it up.
2. Section 5 (Example). "When a failure occurs on the link between PE1 and
P2", but the figure doesn't show these 2 routers as connected..so I'm assuming
you're talking about PE1 and P1 (and later in the text PE2 and P2).
3. Section 6. What is the "null strategy"? Please explain and/or clarify.
4. Section 7. "Ideally this is provided by the remote LFA repair target
advertising this address in the IGP in use. . .out of scope for this document
and must be specified in an IGP specific RFC." What's the importance of even
mentioning this here? If the extensions don't exist and there is a mechanism
that does (using the router ID, as mentioned), then why include something that
doesn't exist..? IMHO, if you want those extensions to be available, then go
define them and then point back to this draft as a way to know where to
establish the session.
Nits
1. Terminology. It would be nice to reorder this section so that terms
defined later are not used to define terms earlier. For example, P-space is
used in the definition on Extended P-space.
2. Introduction. s/many topologies[RFC6571]/many topologies [RFC6571]
(missing space) There are several other places where the space is missing,
which sort of screws up the references in the html version..maybe something
that the RFC Editor will pick up on..I hope.
3. Introduction. s/This technique describes in this document/The technique
described in this document
4. Repair Paths.
s/[I-D.ietf-rtgwg-lfa-manageability].]/[I-D.ietf-rtgwg-lfa-manageability].
5.
4.2 s/protected link S-E.,/protected link S-E,
6. 4.2 s/When released, tunneled packets/When released, packets (not in the
tunnel anymore)
7. 4.2.1 s/Finally we how to compute/Finally we show to compute
8. 4.2.1 s/is provide in/is provided in
9. 4.2.2 s/that member of the set/that the member of the set
10. 4.3 s/pseudo-code provides/pseudo-code provided
11. rfc3137 has been obsoleted by rfc6987
12. 7. s/for the emote LFA/for the remote LFA
13. Section 8.
* I always like results in an Appendix, but that's just me..there may
have been a discussion already about it (similar to the pseudo-code).
* There are some places where some explanation could be useful: what
does the fact that the PQ session could not be established mean? What is the
significance of the percentiles? Etc.. Just to have a more complete report.
* The last few sentences of the section propose other solutions in case
the intersection between P and Q spaces is empty. I think that is out of scope
and should be taken out. As with the suggestion of IGP extensions (section 7),
if there is a specific/complete solution then it should be specified.
14. Section 10 ends with "The following section motivates..", but there is
no such section.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
