Re: Routing directorate QA review for draft-ietf-rtgwg-rlfa-node-protection

[Mike Shand <[e-mail]>]

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"