Alvaro Thanks. Please see inline.
On 22/09/2014 23:55, Alvaro Retana (aretana) 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. > I added some text to address this. > > 1. 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). > I think there were a couple of errors here. Please can people take a look at -7 and makes sure I have not made any other silly errors. > > 1. Section 6. What is the "null strategy"? Please explain and/or clarify. > I have added some text just before to explain that you might assume that node failures with microloops were sufficiently that you might choose to ignore the case. > > 1. 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. > > This text was debated a lot and I would prefer to see it go as is to the next review stage. > 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 > 1..12 done > > 1. 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). > It has been here for a while, can we see what we get in the next round of reviews. > > 1. > * 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. > It is the number of cases where neither LFA nor simple RLFA was adequate - I have added some text. > > 1. > * 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. > I have trimmed this down to In the small number of cases where there is no intersection between the (extended)P-space and the Q-space, a number of solutions to providing a suitable path between such disjoint regions in the network have been discussed in the working group. For example an explicitly routed LSP between P and Q might be set up using RSVP-TE or using Segment Routing [I-D.filsfils-rtgwg-segment-routing]. Such extended repair methods are outside the scope of this document. > 1. > 2. Section 10 ends with "The following section motivates..", but > there is no such section. > Text deleted - Stewart
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
