A couple more comments as I'm writing the shepherd's doc: 1. Please don't forget to look at the idnits: https://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-remote-lfa-06.txt 2. All the references are identified as Informational. I'm thinking that rfc5286 and rfc2119 should be Normative.
Thanks! Alvaro. On 9/22/14 6:55 PM, "Alvaro Retana (aretana)" <[email protected]<mailto:[email protected]>> wrote: 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
