Hello, I have been selected as the Routing Directorate QA reviewer for this draft. https://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-protection-02 General comments ================ This document proposes an interesting approach to the provision of node protection, but I am rather surprised that it does not make even a passing reference to https://tools.ietf.org/html/draft-bryant-ipfrr-tunnels-03 where issues of node protection were first discussed. It would be interesting to see whether the computational complexity of running a reverse SPF at all the next next hop neighbors of E (as proposed there) was greater or less than the solution proposed here of running SPFs at all (or a subset of) the PQ nodes. I'm also surprised that RFC 6571 is not referenced, since that discusses the concept of "de-facto node protecting" which seems very relevant here. There are frequent cases of strictly non-node protecting repairs, which nevertheless ARE effectively node protecting as a result of multiple concurrent (but non-looping) repairs. I think the document needs some work to clarify a few issues (noted below) and fix a large number of nits (also listed below, but there may well be some I have missed in passing). Mike Minor issues =========== para under figure 2 line 3 It would be clearer to say "Extended-P space of S and Q space of E (w.r.t. S-E link)" Note that E itself is also in S's extended P space which makes this rather a strange example. It might be better to devise one where ONLY R3 is in extended P space in order to avoid confusion. So for example in table 3 the route to E would more likely be S=>N=>E Para under table 2 line 2 and 3 "for destinations R3 and D1" I think you mean "destinations "R3 and D2" and again in line 4 "R3 and D2" 2.3 computing node-protecting R-LFA Path para 2 line 2 "we need to ensure that none of the above path segments are unaffected in the event" I assume you mean none are affected (or alternatively all are unaffected) 2.3.1 Computing Candidate Node-protecting PQ-Nodes I THINK you are offering the method in the last two para (using path lists) as an alternative to the previously described method using metrics. If so, it would be helpful to the reader to say this explicitly. para under table 5 (and table 6) Where did node F come from? DO you mean E and D1? and again, by G do you mean D2? NITS ==== Abstract line 2 and 4 (and throughout the document) typos gaurantees -> guarantees 1. Introduction line 2 gaurantees -> guarantee (singular) para 3 line 7 consecutively. I think you mean consequently par 4 line 2 "procedure is extended" line 3 "a complete set" or "complete sets" 2. Node protection with remote-LFA para 1 line 5 "certain operators refrains" -> "certain operators refrain" line 7 "it comes along with" suggest "it introduces" "a must" suggest "essential" para 2 sections discusses -> sections discuss line 2 proposes ->propose "solution for solving the same" why not just "solution". 2.2.1 link-protecting extended p-space para 2 line 3 typo atleast -> at least (and also the same place in 2.2.2 and 2.2.3 and elsewhere) 2.3. computing node-protecting R-LFA path line 2 "comprises of" either "comprises" or better "is comprised of" under table 3 typos extended-p-space inequality And" -> extended-P-space inequality and" para 2 it's ->its 2.3.2 Computing node-protecting paths... para 1 line 3 "procedure in proposed in" -> "procedure as proposed in" para 2 line 6 primary -> the primary para 3 line 11 "PQ nodes that does not" -> "PQ nodes that do not" and also on the next line OR start with "A PQ-node that does not..." etc. 3.1 the problem para 1 line 8 typo befor->before line 10 "comprises two" or "is comprised of two"