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

From: Mike Shand <[email-masked]>
Date: Thu, 1 Oct 2015 11:46:36 +0100

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"

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 1 Oct 2015 17:49:17 +0000

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

>https://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-protection-02
[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.

>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.

>well be some I have missed in passing).
[Pushpasis] Agreed.
>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 
[Pushpasis] Yes. Will correct it.

>I assume you mean none are affected (or alternatively all are unaffected)
[Pushpasis] Yes. Will correct it.
>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.

>and again, by G do you mean D2?
[Pushpasis] Yes. Will correct it.
>"comprises two" or "is comprised of two"
[Pushpasis] Will take care of all the nits. 

Thanks once again :)

>
>
>_______________________________________________
>rtgwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Mike Shand <[email-masked]>
Date: Fri, 2 Oct 2015 10:00:43 +0100

> [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 D…
Sorry, I don't understand. Surely E IS in Q-Space wrt S-E by definition.

Yes, I understand the purpose of the example, and it serves that very 
well. I just thought it may be confusing that the set of potential PQ 
nodes is greater than you had described. That doesn't actually affect 
the point you are making though.

Mike

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 5 Oct 2015 11:51:35 +0000

Hi Mike,

From: Mike Shand
Date: Friday, October 2, 2015 at 2:30 PM
To: Pushpasis Sarkar
Cc: "[email-masked]<mailto:[email-masked]>", 'Jon Hudson'
Subject: Re: Routing directorate QA review for draft-ietf-rtgwg-rlfa-node-protection

Sorry, I don't understand. Surely E IS in Q-Space wrt S-E by definition.
[Pushpasis] Unless the text in RFC-7490 is not wrong, E is not included in Q-Space(S-E). Here is the excerpt from section 5.2.1.3 that says E is not included in Q-Space of (S-E) :-)

“

5.2.1.3.  Q-space

   The set of routers from which the node E can be reached, by normal
   forwarding without traversing the link S-E, is termed the Q-space of
   E with respect to the link S-E.  The Q-space can be obtained by
   computing a reverse Shortest Path Tree (rSPT) rooted at E, with the
   subtree that might traverse the protected link S-E excised (i.e.,
   those nodes that would send the packet via S-E plus those nodes that
   have an ECMP set to E with one or more members of that ECMP set
   traversing the protected link S-E).  The rSPT uses the cost towards
   the root rather than from it and yields the best paths towards the
   root from other nodes in the network.  In the case of Figure 1, the
   Q-space of E with respect to S-E comprises nodes C and D only.
   Expressed in cost terms, the set of routers {Q} are those for which
   the shortest path cost Q<-E is strictly less than the shortest path
   cost Q<-S<-E.  In Figure 1, the intersection of the E's Q-space with
   respect to S-E with S's P-space with respect to S-E defines the set
   of viable repair tunnel endpoints, known as "PQ nodes".  As can be
   seen in the case of Figure 1, there is no common node and hence no
   viable repair tunnel endpoint.  However, when the extended P-space
   (Section 5.2.1.2) at S with respect to S-E is considered, a suitable
   intersection is found at C.

"

Thanks and Regards,
-Pushpasis

Yes, I understand the purpose of the example, and it serves that very well. I just thought it may be confusing that the set of potential PQ nodes is greater than you had described. That doesn't actually affect the point you are making though.

Mike

---

From: Mike Shand <[email-masked]>
Date: Mon, 5 Oct 2015 14:05:17 +0100

Oh dear! Yes, that IS wrong. How did we miss that?

E is certainly in Q space as evidenced by the definition in 2.
The sentence you quote, I guess, is trying to say it is not any of the 
other nodes other than C and D, and perhaps doesn't mention E because it 
is self evidently included. E can clearly reach E without traversing SE.

It really MUST be included.

So for example in the topology

S---E
| /
N

E is in S's extended P-space AND in E's Q-space, and hence is a PQ point 
that can be used to repair S-E. If E is omitted, no repair is possible, 
whereas it clearly IS possible.

Sounds like an error report is in order:-(

Mike

On 05/10/2015 12:51, Pushpasis Sarkar wrote:
> Cc: "[email-masked] <mailto:[email-masked]>", 'Jon Hudson'
> *[Pushpasis] Unless the text in RFC-7490 is not wrong, E is not 
> included in Q-Space(S-E). Here is the excerpt from section 5.2.1.3 
> that says E is not included in Q-Space of (S-E) :-)*
>
> “
> 5.2.1.3. Q-space
>
>     root from other nodes in the network.*In the case of Figure 1, the Q-space of E with respect to S-E 
> comprises nodes C and D only.*
> *Thanks and Regards,*
> *-Pushpasis*

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 5 Oct 2015 16:26:01 +0000

Hi Mike,

I forgot to mention.. Even if we follow the below definition of Extended P-Space from section 2 and 5.1.1.2 in RFC7490…

“Extended P-space:

      Consider the set of neighbors of a router protecting a link.
      Exclude from that set of routers the router reachable over the
      protected link.  The extended P-space of the protecting router
      with respect to the protected link is the union of the P-spaces of
      the neighbors in that set of neighbors with respect to the
      protected link (see Section 5.2.1.2).

“
And
“The description in Section 5.2.1.1 calculated router S's P-space

   rooted at S itself.  However, since router S will only use a repair
   path when it has detected the failure of the link S-E, the initial
   hop of the repair path need not be subject to S's normal forwarding
   decision process.  Thus, the concept of extended P-space is
   introduced.  Router S's extended P-space is the union of the P-spaces
   of each of S's neighbors (N).  This may be calculated by computing an
   SPT at each of S's neighbors (excluding E) and excising the subtree
   reached via the path N->S->E.  Note this will excise those routers
   that are reachable through all ECMPs that include link S-E.  The use
   of extended P-space may allow router S to reach potential repair
   tunnel endpoints that were otherwise unreachable.  In cost terms, a
   router (P) is in extended P-space if the shortest path cost N->P is
   strictly less than the shortest path cost N->S->E->P.  In other
   words, once the packet is forced to N by S, it is a lower cost for it
   to continue on to P by any path except one that takes it back to S
   and then across the S->E link.

"

So if we apply the above definitions in the diagram below from the current draft…

                                             D1
                                            /
                                       S-x-E
                                      /   / \
                                     N---+   R3--D2
                                      \     /
                                      R1---R2

Then Ext-P-Space of S w.r.t S-E link cannot include E and D1 as SPT rooted at N has ECMPs paths traversing the S-E link for destinations E and D1. Basically if S forces a packet destined for E or D1 to N, N can send it back over the path N->S-E. So once again E and D1 cannot be in PQ-space of S wrt S-E link.

Hope this resolves your comment :)

Thanks
-Pushpasis

From: Mike Shand
Date: Monday, October 5, 2015 at 6:35 PM
To: Pushpasis Sarkar
Cc: "[email-masked]<mailto:[email-masked]>", 'Jon Hudson', "Stewart Bryant (stbryant)"
Subject: Re: Routing directorate QA review for draft-ietf-rtgwg-rlfa-node-protection

E is certainly in Q space as evidenced by the definition in 2.
The sentence you quote, I guess, is trying to say it is not any of the other nodes other than C and D, and perhaps doesn't mention E because it is self evidently included. E can clearly reach E without traversing SE.

S---E
| /
N

E is in S's extended P-space AND in E's Q-space, and hence is a PQ point that can be used to repair S-E. If E is omitted, no repair is possible, whereas it clearly IS possible.

Mike

From: Mike Shand
Date: Friday, October 2, 2015 at 2:30 PM
To: Pushpasis Sarkar
Cc: "<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>", 'Jon Hudson'
Subject: Re: Routing directorate QA review for draft-ietf-rtgwg-rlfa-node-protection

“

5.2.1.3.  Q-space

"

Thanks and Regards,
-Pushpasis

Mike

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 5 Oct 2015 17:56:44 +0000

Hi Mike,

My apologies..  I take back the comment below… SPT rooted on N does NOT have S-E link for paths to E and D1..  Sorry for the confusion once again…

I will see if I can come with any example where E and D1 can be excluded from PQ-space… If not I will modify the text to include E and D1 as well…

Regards,
-Pushpasis

From: rtgwg on behalf of Pushpasis Sarkar
Date: Monday, October 5, 2015 at 9:56 PM
To: Mike Shand
Cc: "Stewart Bryant (stbryant)", 'Jon Hudson', "[email-masked]<mailto:[email-masked]>"
Subject: Re: Routing directorate QA review for draft-ietf-rtgwg-rlfa-node-protection

Hi Mike,

“Extended P-space:

“
And

"

                                             D1
                                            /
                                       S-x-E
                                      /   / \
                                     N---+   R3--D2
                                      \     /
                                      R1---R2

Thanks
-Pushpasis

---

From: Mike Shand <[email-masked]>
Date: Mon, 5 Oct 2015 20:10:38 +0100

Ah! so is that + sign supposed to be another node? I had assumed that 
N-E was all one link, and I further assumed that all costs were equal, 
although that isn't stated anywhere. Both of those need to be clarified 
in the text, if indeed that is the case.

On 05/10/2015 17:26, Pushpasis Sarkar wrote:
> Hi Mike,
>
> I forgot to mention.. Even if we follow the below definition of 
> Extended P-Space from section 2 and 5.1.1.2 in RFC7490…
>
> “Extended P-space:
>     reached via the path N->S->E.*Note this will excise those routers that are reachable through all 
> ECMPs that include link S-E.*   The use
> Then Ext-P-Space of S w.r.t S-E link cannot include E and D1 as SPT 
> rooted at N has ECMPs paths traversing the S-E link for destinations E 
> and D1. Basically if S forces a packet destined for E or D1 to N, N 
> can send it back over the path N->S-E. So once again E and D1 cannot 
> be in PQ-space of S wrt S-E link.
>
> Cc: "[email-masked] <mailto:[email-masked]>", 'Jon Hudson', "Stewart 
> Bryant (stbryant)"
> other nodes other than C and D, and perhaps doesn't mention E because 
> it is self evidently included. E can clearly reach E without 
> traversing SE.
>
> E is in S's extended P-space AND in E's Q-space, and hence is a PQ 
> point that can be used to repair S-E. If E is omitted, no repair is 
> possible, whereas it clearly IS possible.
>
>> Cc: "[email-masked]", 'Jon Hudson'

---

From: Mike Shand <[email-masked]>
Date: Mon, 5 Oct 2015 20:11:49 +0100

Ah! OK, I hadn't read this when I replied:-)

Still it would help if the fact that all cost are equal were stated.

     Mike

On 05/10/2015 18:56, Pushpasis Sarkar wrote:
> Hi Mike,
>
> My apologies..  I take back the comment below… SPT rooted on N does 
> NOT have S-E link for paths to E and D1..  Sorry for the confusion 
> once again…
>
> I will see if I can come with any example where E and D1 can be 
> excluded from PQ-space… If not I will modify the text to include E and 
> D1 as well…
>
> Regards,
> -Pushpasis
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 6 Oct 2015 05:40:25 +0000

Sure I will add that in the text.

From: Mike Shand
Date: Tuesday, October 6, 2015 at 12:41 AM
To: Pushpasis Sarkar
Cc: "Stewart Bryant (stbryant)", 'Jon Hudson', "[email-masked]<mailto:[email-masked]>"
Subject: Re: Routing directorate QA review for draft-ietf-rtgwg-rlfa-node-protection

    Mike

Regards,
-Pushpasis

Hi Mike,

“Extended P-space:

“
And

"

                                             D1
                                            /
                                       S-x-E
                                      /   / \
                                     N---+   R3--D2
                                      \     /
                                      R1---R2

Thanks
-Pushpasis