Hi Mike, Thank you very much for the detailed review. I will take care addressing these comments in the next version soon. Please find some comments inline as well.
Regards, -Pushpasis On 10/1/15, 4:16 PM, "rtgwg on behalf of Mike Shand" <[email protected] on behalf of [email protected]> wrote: >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. [Pushpasis] At some point even before publishing the first version on the draft the initial set of authors have initially thought of a similar approach, though we did not exactly refer to the above draft. After analyzing we realized that the number of RSPFs we would have to do depended on the number of Nextnexthops and that set is unbounded. However by virtue standard RLFA procedures we are already getting a list of PQ-nodes. So all we had to do was choose a bounded set of PQ-nodes (that covers most of the destinations in the network) and run FSPF rooted on them. Also as pointed out in the draft, the same F-SPFs also enabled in collecting path attributes for the path segment from the PQ-node to the destination (standard RLFA does not help in there) which helps in doing proper LFA manageability for the RLFA backup paths. > >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. [Pushpasis] Frankly, we have never discussed this before publishing the draft or even after in the working-group. But upon my first look it seems ‘de facto’ node-protection relies on neighbor nodes of the PLR implementing LFA as well (my understanding maybe wrong). Our goal was to keep the solution local to the PLR and not rely on the neighbor nodes implementing any kind of LFA as well. > >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)" [Pushpasis] Agreed. > > >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. [Pushpasis] But then E should not be in Q-Space(S-E) and hence it will not be a PQ-node. The goal of this example was to show that while PQ node R2 provides node protection for destination R3 and D2(in the text it says R1, I will rectify it) the PQ-node R3 does not provide node-protection for the same destinations R3 and D2. This example was specifically carved to show that not only the path from PQ-node to destination must avoid primary next hop E, but also all paths from S to the PQ-node as well. >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" [Pushpasis] Yes. Will correct it. > >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) [Pushpasis] Yes. Will correct it. > >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. [Pushpasis] No. This section just tells how to compute list of node-protecting PQ-nodes (PQ-nodes for which the path from S to PQ-nodes is node-protecting). The idea is once we have a subset of PQ-nodes for which the path from S to PQ-node is node-protected, the procedure in section 2.3.2 will be executed to check if the path from the PQ-node is also node-protected. > >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? [Pushpasis] Yes. Will correct it. > > >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" [Pushpasis] Will take care of all the nits. Thanks once again :) > > >_______________________________________________ >rtgwg mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
