Subject: Re: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 27 Oct 2015 18:00:55 +0000

Hi Mike,

From: Mike Shand <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 27, 2015 at 10:35 PM
To: Levente Csikor <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>
Subject: Re: FW: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt

Levente,

    Some good points that I missed in my review.

    Mike

On 27/10/2015 15:56, Levente Csikor wrote:
Dear Pushpasis,

I've read the new version of the draft, and I find some ambiguous statements/terms and mistakes. Sorry that I did not read it before the 4th revision.

1)Terms:
To be consistent, in Section 2. first-hop should be named/termed as next-hop, since in each latter case it is termed as next-hop (or nexthop).
And later the term primary node also rises the question whether it means next-hop, or something else.
Next-hop is the conventional term
[Pushpasis] Sure I will use the same in next version.

2)Ambiguous things:
On page 4, the Topology 2 introduced in Fig.2., is a bit ambiguous, since we are talking about (remote) loop-free alternates, but some cells in Table 2's Remote-LFA Back Path column contain loops, namely S=>N=>E=>R3->E->D1,S=>N=>E=>R3->E. In my opinion, this case can be understood if I take a look on the topology over and over again (to find and indentify remote LFAs), but according to RFC 7490, shouldn't we rely on simple LFA (node N in the topology) in such cases when they are available?
Probably a better and unambiguous example topology would be better, or it should be stated that in such case node N could be a pure link-protecting LFA.
Yes, I had already pointed out that this was a poor example, since in fact the node E itself is a valid PQ, point, being in the extended P-space of S w.r.t. S-E and trivially in E's Q-space w.r.t. S-E.

And yes, there is no need to use an RLFA tunnel when a simple LFA already exists.

I really think a less ambiguous, and perhaps more general, example is required here..
[Pushpasis] Once again the goal of this example was to show that while the repair tunnel for some PQ-node can traverse through the primary next hop node (and hence cannot be node-protecting) repair tunnel for other PQ-nodes may not traverse the primary next hop node and hence can be considered as a candidate for node-protecting PQ-node. I tried my best to come up with an alternative example that depicts the same, but  I could not. If anyone provide me a better example I shall be very thankful.

3)Mistake:
Section 2.2.1 on page 6 states the following about link protecting extended P-space:
"A node Y is in link-protecting extended P-space w.r.t to the link (S-E) being protected, if and only if, there exists at least one direct neighbor of S, Ni, other than primary nexthop E, that satisfies the following condition.
   D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y)"

The document also states that this inequality is already defined in RFC7490.
However, this inequality seems to be wrong, or it is not properly prepared.
To me, in essence, this inequality states (assuming that Y is the neighbor of Ni) is that my neighbor's (Ni) neighbor (Y) is closer to my neighbor (Ni) than me (S), which is almost every time true, but what if my neighbor's (Ni) neighbor (Y) is my (S) neighbor as well?
Consider the topology below, where 'x' denotes only the failure on link S-E, while all the links are of unit cost except the link Ni-Y, where the cost is 2:

  Y
2/ \
Ni--S--x--E
|        /
B       D
 \     /
  \   /
   \ /
    A

In this case, Y does not fulfill the inequality stated above, however, it's in extended P-space, moreover, it's in P-space as well, and as far as I remember, ext.P-space always consists of the (smaller) P-space.
I think the main problem here is that there is no cross-reference to the failed link itself (as it is in node-protecting P-space inequality).
Therefore, this could be resolved by the following inequality:
   D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,E) + D_opt(E, Y)

Yes, you are correct. The critical part about traversing the failed link was missing. I always find the cost based formulations of LFA properties error prone, which is why I prefer not to use them.
[Pushpasis] Y is indeed in the P-space of S wrt S-E link. And hence also in Ext-P space of S wrt S-E by definition. And I have shown in my previous response to Levente that Y satisfies the above inequality.

Or, the statement should emphasize in the beginning that node Y is not in the P-space of S w.r.t. the failed link S-E.
Pls tell me if I'm wrong.
Btw, the inequality for node-protecting extended P-space is valid.

4)
Section 2.2.3
"The Remote-LFA [RFC7490] draft already defines this.  The Q-space for a link S-E being protected is the set of routers that can reach primary node E,..."
In this case, the term primary node is again equivocal, since if it means next-hop, then the definition is wrong. RFC7490 defines Q-spaces for the routers/nodes, however, if we talk about to find a remote LFA for a given source-destination pair w.r.t. a failed element, then (ext.) P-space of the source, and the Q-space of the destination should be evaluated/calculated (w.r.t. the failed element).
In my opinion Q space should always be referred to as being the Q space of a node with respect to a link. So we should here talk about the Q space of node E w.r.t. link S-E as being "the set of routers (Y) that can reach E without traversing the link S-E on any of the shortest paths from node Y to node E". Talking about primary node and primary next-hop is superfluous and is indeed confusing.
[Pushpasis] With due respect, I will like to disagree. The node E has a dependency on the S-E link being protected. The node E is being considered here because it is at the other end of the S-E link, and not just another node unrelated to the link being protected. The node E IS the primary node/next-hop since S-E is the primary link being protected here. If S-E would not be the primary link for any destination, what will be the reason for computing P, Ext-P, Q and PQ spaces for it?

To my understanding, the intention of computing Q-space is to find a node also in the Extended-P-Space (so that you can tunnel the backup traffic to it without traversing the S-E link) that will not traverse the S-E link while being hop-by-hop forwarded to the final destination being originally reachable via S-E link (and hence via the node E).

Later, in section 2.2.5.:
"A node Y is in candidate node-protecting PQ space w.r.t to the node(E) being protected, if and only if, Y is present in both node-protecting extended P-space and the Q-space for the link being protected."
To me, the term "..Q-space for the link being protected" is again not properly stated.

Agreed. It should reference E. i.e. the Q-space of E w.r.t to S-E
[Pushpasis] Again I think Q-Space is always wrt to node S(the PLR) and S-E link(primary link being considered to be protected).

5)
My final problem probably remains my problem :), but from section 2.2.5, there are a lot of reference to the term PQ-space, or PQ-node, for instance, in section 2.3.1:
"As mentioned in Section 2.2.2, to consider a PQ-node as candidate node-protecting PQ-node, there must be at least one direct neighbor Ni of S, such that all shortest paths from Ni to the PQ-node does not traverse primary nexthop node E."
or
"To determine if a given candidate node-protecting PQ-node provides node-protecting alternate for a given destination, the primary nexthop node should not be on any of the shortest paths from the PQ-node to the given destination."

and it occurs in many sentences.

Basically what a bit confusing here is that according to RFC7490, if a set of routers is termed PQ-nodes, or even PQ-space, then they already fulfill the inequalities for (ext.) P-space and Q-space. So, in the above-mentioned sentences, it's a bit confusing why are we checking Q-space inequality if it's already a PQ-node. Probably better placements of the word "candidate" could resolve this issue, or we should rely on "node in P-space" or "node in Q-space" instead of PQ-node candidate.
On the other hand, if we talk about a PQ-node candidate, then it means (at least to me) that the node fulfills at least one of the inequalities, i.e., it is already in the Q-space or the (ext.) P-space, and therefore we say it's a candidate if it fulfills the remaining inequality as well.

Agreed. It is somewhat tautologous!
[Pushpasis] I will try to remove the confusion in next version.

Thanks and Regards,
-Pushpasis

6) Typo on page 10
"As seen in the above example above" -> As seen in the example above

Thanks, and please don't consider my observations offending, I'm just try to understand the whole concept of remote LFAs and try to help and improve the draft itself.

Best regards,
Levente

On 10/14/2015 11:51 AM, Pushpasis Sarkar wrote:

Hi Mike,

I have addressed all the comments I have received so far. Here is the updated version of the draft.

Thanks
-Pushpasis

On 10/14/15, 3:19 PM, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> wrote:

A new version of I-D, draft-ietf-rtgwg-rlfa-node-protection-04.txt
has been successfully submitted by Pushpasis Sarkar and posted to the
IETF repository.

Name:           draft-ietf-rtgwg-rlfa-node-protection
Revision:       04
Title:          Remote-LFA Node Protection and Manageability
Document date:  2015-10-14
Group:          rtgwg
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-rlfa-node-protection-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/
Htmlized:       https://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-protection-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-rlfa-node-protection-04

Abstract:
  The loop-free alternates computed following the current Remote-LFA
  [RFC7490] specification guarantees only link-protection.  The
  resulting Remote-LFA nexthops (also called PQ-nodes), may not
  guarantee node-protection for all destinations being protected by it.

  This document describes procedures for determining if a given PQ-node
  provides node-protection for a specific destination or not.  The
  document also shows how the same procedure can be utilised for
  collection of complete characteristics for alternate paths.
  Knowledge about the characteristics of all alternate path is
  precursory to apply operator defined policy for eliminating paths not
  fitting constraints.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: Mike Shand <[email-masked]>
Date: Tue, 27 Oct 2015 18:26:19 +0000

Hi Pushpasis,

What you say about Q space is not in itself wrong. However, it is 
introducing a definition of Q space which is different, although 
semantically the same, as that previously used, for example in RFC 7490.

Q space has always been thought of as a property of a node (E usually) 
and a link (S-E usually). Hence RFC 7490 defines it as

       The Q-space of a router with respect to a protected link is the
       set of routers from which that specific router can be reached
       without any path (including equal-cost path splits) transiting
       that protected link.

The concept of Q space is then used in fast-reroute techniques where, as 
you rightly describe, we are concerned with
calculating the Q space of the next-hop node from a particular PLR. 
(i.e. S, typically).

But my feeling is that to introduce this apparently different definition 
will be confusing in the long term.

Mike

On 27/10/2015 18:00, Pushpasis Sarkar wrote:
> Hi Mike,
>
>
> From: Mike Shand <[email-masked] <mailto:[email-masked]>>
> To: Levente Csikor <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked] 
> <mailto:[email-masked]>>
> Subject: Re: FW: New Version Notification for 
> draft-ietf-rtgwg-rlfa-node-protection-04.txt
>
>
> Levente,
>
>> I've read the new version of the draft, and I find some ambiguous 
>> statements/terms and mistakes. Sorry that I did not read it before 
>> the 4th revision.
>>
>> 1)Terms:
>> To be consistent, in Section 2. first-hop should be named/termed as 
>> next-hop, since in each latter case it is termed as next-hop (or 
>> nexthop).
> *[Pushpasis] Sure I will use the same in next version. *
>>
>> 2)Ambiguous things:
>> On page 4, the Topology 2 introduced in Fig.2., is a bit ambiguous, 
>> since we are talking about (remote) *loop-free* alternates, but some 
>> cells in Table 2's Remote-LFA Back Path column contain loops, namely 
>> S=>N=>E=>R3->E->D1,S=>N=>E=>R3->E. In my opinion, this case can be 
>> understood if I take a look on the topology over and over again (to 
>> find and indentify remote LFAs), but according to RFC 7490, shouldn't 
>> we rely on simple LFA (node N in the topology) in such cases when 
>> they are available?
>> Probably a better and unambiguous example topology would be better, 
>> or it should be stated that in such case node N could be a pure 
>> link-protecting LFA.
> Yes, I had already pointed out that this was a poor example, since in 
> fact the node E itself is a valid PQ, point, being in the extended 
> P-space of S w.r.t. S-E and trivially in E's Q-space w.r.t. S-E.
>
> *[Pushpasis] Once again the goal of this example was to show that 
> while the repair tunnel for some PQ-node can traverse through the 
> primary next hop node (and hence cannot be node-protecting) repair 
> tunnel for other PQ-nodes may not traverse the primary next hop node 
> and hence can be considered as a candidate for node-protecting 
> PQ-node. I tried my best to come up with an alternative example that 
> depicts the same, but I could not. If anyone provide me a better 
> example I shall be very thankful.*
>
>>
>>
>> 3)Mistake:
>> "A node Y is in link-protecting extended P-space w.r.t to the link 
>> (S-E) being protected, if and only if, there exists at least one 
>> direct neighbor of S, Ni, other than primary nexthop E, that 
>> satisfies the following condition.
>> To me, in essence, this inequality states (assuming that Y is the 
>> neighbor of Ni) is that my neighbor's (Ni) neighbor (Y) is closer to 
>> my neighbor (Ni) than me (S), which is almost every time true, but 
>> what if my neighbor's (Ni) neighbor (Y) is my (S) neighbor as well?
>> Consider the topology below, where 'x' denotes only the failure on 
>> link S-E, while all the links are of unit cost except the link Ni-Y, 
>> where the cost is 2:
>>
>>   Y
>> 2/ \
>> Ni--S--x--E
>> |        /
>> B       D
>>  \     /
>>   \   /
>>    \ /
>>     A
>>
>> In this case, Y does not fulfill the inequality stated above, 
>> however, it's in extended P-space, moreover, it's in P-space as well, 
>> and as far as I remember, ext.P-space always consists of the 
>> (smaller) P-space.
>> I think the main problem here is that there is no cross-reference to 
>> the failed link itself (as it is in node-protecting P-space inequality).
> Yes, you are correct. The critical part about traversing the failed 
> link was missing. I always find the cost based formulations of LFA 
> properties error prone, which is why I prefer not to use them.
> *[Pushpasis] Y is indeed in the P-space of S wrt S-E link. And hence 
> also in Ext-P space of S wrt S-E by definition. And I have shown in my 
> previous response to Levente that Y satisfies the above inequality.*
> *
> *
>
>
>> Or, the statement should emphasize in the beginning that node Y is 
>> not in the P-space of S w.r.t. the failed link S-E.
>> "The Remote-LFA [RFC7490] draft already defines this.  The Q-space 
>> for a link S-E being protected is the set of routers that can reach 
>> primary node E,..."
>> In this case, the term primary node is again equivocal, since if it 
>> means next-hop, then the definition is wrong. RFC7490 defines 
>> Q-spaces for the routers/nodes, however, if we talk about to find a 
>> remote LFA for a given source-destination pair w.r.t. a failed 
>> element, then (ext.) P-space of the source, and the Q-space of the 
>> destination should be evaluated/calculated (w.r.t. the failed element).
> In my opinion Q space should always be referred to as being the Q 
> space of a node with respect to a link. So we should here talk about 
> the Q space of node E w.r.t. link S-E as being "the set of routers (Y) 
> that can reach E without traversing the link S-E on any of the 
> shortest paths from node Y to node E". Talking about primary node and 
> primary next-hop is superfluous and is indeed confusing.
> *[Pushpasis] With due respect, I will like to disagree. The node E has 
> a dependency on the S-E link being protected. The node E is being 
> considered here because it is at the other end of the S-E link, and 
> not just another node unrelated to the link being protected. The node 
> E IS the primary node/next-hop since S-E is the primary link being 
> protected here. If S-E would not be the primary link for any 
> destination, what will be the reason for computing P, Ext-P, Q and PQ 
> spaces for it? *
> *
> *
> *To my understanding, the intention of computing Q-space is to find a 
> node also in the Extended-P-Space (so that you can tunnel the backup 
> traffic to it without traversing the S-E link) that will not traverse 
> the S-E link while being hop-by-hop forwarded to the final destination 
> being originally reachable via S-E link (and hence via the node E).*
>
>>
>> "A node Y is in candidate node-protecting PQ space w.r.t to the 
>> node(E) being protected, if and only if, *Y is present in both 
>> node-protecting extended P-space and the Q-space for the link being 
>> protected.*"
> *[Pushpasis] Again I think Q-Space is always wrt to node S(the PLR) 
> and S-E link(primary link being considered to be protected).*
>
>>
>>
>> 5)
>> My final problem probably remains my problem :), but from section 
>> 2.2.5, there are a lot of reference to the term PQ-space, or PQ-node, 
>> for instance, in section 2.3.1:
>> "As mentioned in Section 2.2.2, to consider a PQ-node as candidate 
>> node-protecting PQ-node, there must be at least one direct neighbor 
>> Ni of S, such that all shortest paths from Ni to the PQ-node does not 
>> traverse primary nexthop node E."
>> or
>> "To determine if a given candidate node-protecting PQ-node provides 
>> node-protecting alternate for a given destination, the primary 
>> nexthop node should not be on any of the shortest paths from the 
>> PQ-node to the given destination."
>>
>> Basically what a bit confusing here is that according to RFC7490, if 
>> a set of routers is termed PQ-nodes, or even PQ-space, then they 
>> already fulfill the inequalities for (ext.) P-space and Q-space. So, 
>> in the above-mentioned sentences, it's a bit confusing why are we 
>> checking Q-space inequality if it's already a PQ-node. Probably 
>> better placements of the word "candidate" could resolve this issue, 
>> or we should rely on "node in P-space" or "node in Q-space" instead 
>> of PQ-node candidate.
>> On the other hand, if we talk about a PQ-node candidate, then it 
>> means (at least to me) that the node fulfills at least one of the 
>> inequalities, i.e., it is already in the Q-space or the (ext.) 
>> P-space, and therefore we say it's a candidate if it fulfills the 
>> remaining inequality as well.
>
> *[Pushpasis] I will try to remove the confusion in next version.*
> *
> *
> *Thanks and Regards,*
> *-Pushpasis*
>
>>
>>
>>
>> 6) Typo on page 10
>> Thanks, and please don't consider my observations offending, I'm just 
>> try to understand the whole concept of remote LFAs and try to help 
>> and improve the draft itself.
>>
>>
>> Best regards,
>> Levente
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 10/14/15, 3:19 PM,"[email-masked]"  <[email-masked]>  wrote:
>>>
>>>> URL:https://www.ietf.org/internet-drafts/draft-ietf-rtgwg-rlfa-node-protection-04.txt
>>>> Status:https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/
>>>> Htmlized:https://tools.ietf.org/html/draft-ietf-rtgwg-rlfa-node-protection-04
>>>> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-rlfa-node-protection-04
>>>>
>>>> Abstract:
>>> [email-masked]://www.ietf.org/mailman/listinfo/rtgwg
>>
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 27 Oct 2015 18:37:22 +0000

Hi Mike,

From: Mike Shand <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 27, 2015 at 11:56 PM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Levente Csikor <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt

Hi Pushpasis,

What you say about Q space is not in itself wrong. However, it is introducing a definition of Q space which is different, although semantically the same, as that previously used, for example in RFC 7490.

Q space has always been thought of as a property of a node (E usually) and a link (S-E usually). Hence RFC 7490 defines it as

The concept of Q space is then used in fast-reroute techniques where, as you rightly describe, we are concerned with
calculating the Q space of the next-hop node from a particular PLR. (i.e. S, typically).

But my feeling is that to introduce this apparently different definition will be confusing in the long term.
[Pushpasis] I really don’t see the difference.. I just see the extra words “primary node E” instead of “router E”.. It is getting little difficult for me to get where is the confusion.. Anyways, I will try to re-word as much as possible to remove any probable confusions in next version...

Thanks and Regards,
-Pushpasis

Mike

From: Mike Shand <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 27, 2015 at 10:35 PM
To: Levente Csikor <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>
Subject: Re: FW: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt

Levente,

    Mike

1)Terms:

2)Ambiguous things:

3)Mistake:

  Y
2/ \
Ni--S--x--E
|        /
B       D
 \     /
  \   /
   \ /
    A

4)
Section 2.2.3

5)

Thanks and Regards,
-Pushpasis

6) Typo on page 10

Best regards,
Levente

Hi Mike,

Thanks
-Pushpasis

Abstract:

The IETF Secretariat

---

From: Levente Csikor <[email-masked]>
Date: Wed, 28 Oct 2015 10:11:54 +0100

Hi,
My problem is something similar.
It's true that instead of calculating rLFAs not as per-prefix, but as 
per-link provides backup routes probably for more source-destination 
pairs as it was in the case of pure LFA.
If this is the case then Q-space should be defined for the next-hop, and 
this need to be emphasized in the document (the text in section 2.2.3. 
only talks about primary node E, and link S-E, but reader may not know 
whether E is the destination as well).
If the former is true, then the definition should be refined 
accordingly, for instance:

For source s, destination d, and next-hop e, some n ! = s, d is a 
node-protecting Remote LFA for *the s − d pair* if and only if
i) there exists a node (V \in neigh(s)) : D_opt(v, n) < D_opt(v, e) + 
D_opt(e, n)  --- ext.P-space, where neigh(s) is the set of the direct 
neighbors of s
ii)  D_opt(n, d) < D_opt(n, e) + D_opt(e, d) -- Q-space
(the above definitions are taken from [1], where we always assumed that 
remote LFA calculation is done for a given source-destination pair)

As an example to illustrate the difference between the terms, check the 
following example:

                                     S-x-E
                                    /     \
                                   A       D---G
                                    \     /    |
                                     B---C     |3
                                      \ /2     |
                                       F-------H
Assume that S wants to send a packet to G and as indicated with 'x', the 
link S-E fails, and again all links are of unit costs except F-C and 
H-G, where link cost is 2 and 3, respectively.
The shortest path from S to G is clearly S-E-D-G.

In this case, when we calculate the Q-space of E, then it will consists 
of ((E),D,G,C).
However, if we calculate the Q-space of the destination node G itself, 
then Q-space will consists of (E, D, (G), C, *B, F* and *H* *as well*).
So, since the simple P-space of S consists of A,B,F,H; while ext.P-space 
consists of additionally node C and node G as well, the set of the 
PQ-nodes are bigger.
Tell me, if miscalculated something in the example.

Regards,
Levente

[1] L. Csikor and G. Rétvári, “On Providing Fast Protection with Remote 
Loop-Free Alternates – Analyzing and Optimizing Unit Cost Networks,” 
Telecommunication Systems Journal, 2015

On 10/27/2015 07:26 PM, Mike Shand wrote:
> The concept of Q space is then used in fast-reroute techniques where, 
> as you rightly describe, we are concerned with
> But my feeling is that to introduce this apparently different 
> definition will be confusing in the long term.
>
> Mike
>
>
>> From: Mike Shand <[email-masked]>
>> To: Levente Csikor <[email-masked]>, "[email-masked] 
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
>> Pushpasis Sarkar <[email-masked] <mailto:[email-masked]>>
>>> find and indentify remote LFAs), but according to RFC 7490, 
>>> shouldn't we rely on simple LFA (node N in the topology) in such 
>>> cases when they are available?
>>> however, it's in extended P-space, moreover, it's in P-space as 
>>> well, and as far as I remember, ext.P-space always consists of the 
>>> (smaller) P-space.
>> also in Ext-P space of S wrt S-E by definition. And I have shown in 
>> my previous response to Levente that Y satisfies the above inequality.*
>> *
>> *
>>
>>
>> the Q space of node E w.r.t. link S-E as being "the set of routers 
>> (Y) that can reach E without traversing the link S-E on any of the 
>> *[Pushpasis] With due respect, I will like to disagree. The node E 
>> has a dependency on the S-E link being protected. The node E is being 
>> the S-E link while being hop-by-hop forwarded to the final 
>> destination being originally reachable via S-E link (and hence via 
>> the node E).*
>>
>>>
>>> 2.2.5, there are a lot of reference to the term PQ-space, or 
>>> PQ-node, for instance, in section 2.3.1:
>>> Ni of S, such that all shortest paths from Ni to the PQ-node does 
>>> not traverse primary nexthop node E."
>>> or
>>> Thanks, and please don't consider my observations offending, I'm 
>>> just try to understand the whole concept of remote LFAs and try to 
>>> help and improve the draft itself.
>>>
>>>
>>> Best regards,
>>> Levente
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

---

From: Levente Csikor <[email-masked]>
Date: Wed, 28 Oct 2015 10:15:28 +0100

Sorry, the topology may have fallen into several piecesdue to not 
setting 'fixed width' when composed the previous message.

      S-x-E
     /     \
    A       D---G
     \     /    |
      B---C     |3
       \ /2     |
        F-------H

Regards,
Levente

On 10/28/2015 10:11 AM, Levente Csikor wrote:
> If this is the case then Q-space should be defined for the next-hop, 
> and this need to be emphasized in the document (the text in section 
> 2.2.3. only talks about primary node E, and link S-E, but reader may 
> not know whether E is the destination as well).
> (the above definitions are taken from [1], where we always assumed 
> that remote LFA calculation is done for a given source-destination pair)
>
> As an example to illustrate the difference between the terms, check 
> the following example:
>
>                                     S-x-E
>                                    /     \
>                                   A       D---G
>                                    \     /    |
>                                     B---C     |3
>                                      \ /2     |
>                                       F-------H
> Assume that S wants to send a packet to G and as indicated with 'x', 
> the link S-E fails, and again all links are of unit costs except F-C 
> and H-G, where link cost is 2 and 3, respectively.
> In this case, when we calculate the Q-space of E, then it will 
> consists of ((E),D,G,C).
> So, since the simple P-space of S consists of A,B,F,H; while 
> ext.P-space consists of additionally node C and node G as well, the 
> set of the PQ-nodes are bigger.
> [1] L. Csikor and G. Rétvári, “On Providing Fast Protection with 
> Remote Loop-Free Alternates – Analyzing and Optimizing Unit Cost 
> Networks,” Telecommunication Systems Journal, 2015
>
>
>
>
>> Q space has always been thought of as a property of a node (E 
>> usually) and a link (S-E usually). Hence RFC 7490 defines it as
>>>> since we are talking about (remote) *loop-free* alternates, but 
>>>> some cells in Table 2's Remote-LFA Back Path column contain loops, 
>>>> namely S=>N=>E=>R3->E->D1,S=>N=>E=>R3->E. In my opinion, this case 
>>>> can be understood if I take a look on the topology over and over 
>>>> again (to find and indentify remote LFAs), but according to RFC 
>>>> 7490, shouldn't we rely on simple LFA (node N in the topology) in 
>>>> such cases when they are available?
>>> Yes, I had already pointed out that this was a poor example, since 
>>> in fact the node E itself is a valid PQ, point, being in the 
>>> extended P-space of S w.r.t. S-E and trivially in E's Q-space w.r.t. 
>>> S-E.
>>>
>>>> neighbor of Ni) is that my neighbor's (Ni) neighbor (Y) is closer 
>>>> to my neighbor (Ni) than me (S), which is almost every time true, 
>>>> but what if my neighbor's (Ni) neighbor (Y) is my (S) neighbor as 
>>>> well?
>>>> link S-E, while all the links are of unit cost except the link 
>>>> Ni-Y, where the cost is 2:
>>>>
>>>>   Y
>>>> 2/ \
>>>> Ni--S--x--E
>>>> |        /
>>>> B       D
>>>>  \     /
>>>>   \   /
>>>>    \ /
>>>>     A
>>>>
>>>> I think the main problem here is that there is no cross-reference 
>>>> to the failed link itself (as it is in node-protecting P-space 
>>>> inequality).
>>> shortest paths from node Y to node E". Talking about primary node 
>>> and primary next-hop is superfluous and is indeed confusing.
>>> has a dependency on the S-E link being protected. The node E is 
>>> being considered here because it is at the other end of the S-E 
>>> link, and not just another node unrelated to the link being 
>>> protected. The node E IS the primary node/next-hop since S-E is the 
>>> primary link being protected here. If S-E would not be the primary 
>>> link for any destination, what will be the reason for computing P, 
>>> Ext-P, Q and PQ spaces for it? *
>>> *
>>> *
>>> *To my understanding, the intention of computing Q-space is to find 
>>> a node also in the Extended-P-Space (so that you can tunnel the 
>>> backup traffic to it without traversing the S-E link) that will not 
>>> traverse the S-E link while being hop-by-hop forwarded to the final 
>>>> Basically what a bit confusing here is that according to RFC7490, 
>>>> if a set of routers is termed PQ-nodes, or even PQ-space, then they 
>>>> already fulfill the inequalities for (ext.) P-space and Q-space. 
>>>> So, in the above-mentioned sentences, it's a bit confusing why are 
>>>> we checking Q-space inequality if it's already a PQ-node. Probably 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Mike Shand <[email-masked]>
Date: Wed, 28 Oct 2015 11:20:35 +0000

You raise an interesting point about per-link or per-prefix protection. 
In the existing RLFA it is per-link protection (but of course simple LFA 
is per prefix). Clearly per prefix is always possible, but involves the 
computation of the Q space of every destination wrt the failed link, 
which can get computationally expensive. The compromise reached in the 
original node protecting work was to compute the Q space at each 
next-next hop wrt the failed link. Clearly this too, can result in many 
Q space computations where there are many next-next hops.

I think the present document needs some clarification about exactly what 
it is attempting to provide.

Mike

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 28 Oct 2015 12:29:04 +0000

Hi Levente,

From: Levente Csikor <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 28, 2015 at 2:41 PM
To: Mike Shand <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-ietf-rtgwg-rlfa-node-protection-04.txt

Hi,
My problem is something similar.
It's true that instead of calculating rLFAs not as per-prefix, but as per-link provides backup routes probably for more source-destination pairs as it was in the case of pure LFA.
If this is the case then Q-space should be defined for the next-hop, and this need to be emphasized in the document (the text in section 2.2.3. only talks about primary node E, and link S-E, but reader may not know whether E is the destination as well).
If the former is true, then the definition should be refined accordingly, for instance:

For source s, destination d, and next-hop e, some n ! = s, d is a node-protecting Remote LFA for the s − d pair if and only if
i) there exists a node (V \in neigh(s)) : D_opt(v, n) < D_opt(v, e) + D_opt(e, n)  --- ext.P-space, where neigh(s) is the set of the direct neighbors of s
ii)  D_opt(n, d) < D_opt(n, e) + D_opt(e, d) -- Q-space
(the above definitions are taken from [1], where we always assumed that remote LFA calculation is done for a given source-destination pair)

As an example to illustrate the difference between the terms, check the following example:

                                    S-x-E
                                   /     \
                                  A       D---G
                                   \     /    |
                                    B---C     |3
                                     \ /2     |
                                      F-------H

Assume that S wants to send a packet to G and as indicated with 'x', the link S-E fails, and again all links are of unit costs except F-C and H-G, where link cost is 2 and 3, respectively.
The shortest path from S to G is clearly S-E-D-G.

In this case, when we calculate the Q-space of E, then it will consists of ((E),D,G,C).
However, if we calculate the Q-space of the destination node G itself, then Q-space will consists of (E, D, (G), C, B, F and H as well).
So, since the simple P-space of S consists of A,B,F,H; while ext.P-space consists of additionally node C and node G as well, the set of the PQ-nodes are bigger.
Tell me, if miscalculated something in the example.

[Pushpasis] Here is an excerpt from RFC7490 section 5.2.1.3 that better addresses your concern :)

“

   Note that the Q-space calculation could be conducted for each
   individual destination and a per-destination repair tunnel end point
   determined.  However, this would, in the worst case, require an SPF
   computation per destination that is not currently considered to be
   scalable.  Therefore, the Q-space of E with respect to link S-E is
   used as a proxy for the Q-space of each destination.  This
   approximation is obviously correct since the repair is only used for
   the set of destinations which were, prior to the failure, routed
   through node E.  This is analogous to the use of link LFAs rather
   than per-prefix LFAs.

“
Thanks
-Pushpasis

Regards,
Levente

[1] L. Csikor and G. Rétvári, “On Providing Fast Protection with Remote Loop-Free Alternates – Analyzing and Optimizing Unit Cost Networks,” Telecommunication Systems Journal, 2015

Mike

Levente,

    Mike

1)Terms:

2)Ambiguous things:

3)Mistake:

  Y
2/ \
Ni--S--x--E
|        /
B       D
 \     /
  \   /
   \ /
    A

4)
Section 2.2.3

5)

Thanks and Regards,
-Pushpasis

6) Typo on page 10

Best regards,
Levente

Hi Mike,

Thanks
-Pushpasis

Abstract:

The IETF Secretariat