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

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 27 Oct 2015 17:31:53 +0000

Hi Levente,

Thanks a lot for the detailed review and comments. I will try to address them inline.

Best Regards,
-Pushpasis

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

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.
[Pushpasis] They all mean the same I.e. Primary next-hop(s) except for the cases which talks about the backup/alternate next-hops. Alternate/backup next hops maybe immediate neighbor (in case of standard RFC5286 LFA) or remote nodes (in case of Remote LFA). I will modify the text to be consistent 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?
[Pushpasis] Yes RFC 7490 says that LFA backup paths should be more preferrable than RLFA bcakup paths. However this table talks about possible RLFA paths via the PQ-nodes to depict cases where while the backup paths to certain PQ-nodes computed provides node-protection it does not for others. We spent a lot of time to come up with example to depict the same, but could not come up with a better example to depict that. Probably you can help us with a better topology if you have in mind :)

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.

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)

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.
[Pushpasis] I think you might have misunderstood it.. Ni is not a single neighbor of S.. The term Ni in the above inequality stands for all neighbors of S other than E (primary next hop).. Here is the text once more..

"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)"

So one possible value for Ni can be Y itself..  So now if you substitute Y for Ni in the above inequality it satisfies the inequality..

D_opt(Y, Y) < D_opt(Y,S) + D_opt(S,Y)
              0                     1                     1

However to make it more clear let me rename the Nodes Ni and Y in the above diagram as N1 and N2. So the diagram now looks like..

  N2
2/ \
N1--S--x--E
|        /
B       D
 \               /
    \         /
       \   /
         A

Ni = {N1, N2}

Now with N2 as the candidate,

substituting Ni = N1

D_opt(N1, N2) < D_opt(N1,S) + D_opt(S,N2) is not satisfied
                  2                         1                          1

However substituting Ni = N2

D_opt(N2, N2) < D_opt(N2,S) + D_opt(S,N2) is indeed satisfied
                  0                        1                          1

So N2 is in link-protecting Ext-P-Space of S, wrt S-E link.

Essentially for Y to be in link-protected Extended P-Space(S, S-E) S (or one of the neighbors of S other than E) should be able to reach Y without taversing the S-E link.. The above inequality is satisfied by substituting Ni as Y.

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

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.
[Pushpasis] Q-Space by definition [RFC 7490] is always wrt to primary next-hop link S-E being protected. There is no separate link-protecting or node-protecting Q-Space. Node-protecting P, Ext-P and PQ-space is wrt to both the primary next-hop link S-E and primary next-hop node E being protected. I will modify the text accordingly.

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.
[Pushpasis] The term 'PQ-node' here means RFC 7490 computed link-protecting PQ-node. However the inequality being applied here is for a link-protecting PQ-node that is also considered as a candidate for being a node-protecting PQ-node. Once again I will try modifying the text to remove any such confusion.

6) Typo on page 10
"As seen in the above example above" -> As seen in the example above
[Pushpasis] Will correct it.

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.
[Pushpasis] Not all. Once again thank you very much for the detailed review.

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: Levente Csikor <[email-masked]>
Date: Wed, 28 Oct 2015 09:34:16 +0100

Dear Pushpasis,
I agree with you with the previous observations, except the following 
can not gracefully leave my mind :)

Tell me if I did not get your point, but according to your inequalities, 
it seems that N2 being evaluated at first gives an error, i.e.,
/
//"D_opt(N1, N2) < D_opt(N1,S) + D_opt(S,N2) is not satisfied//
//    2              1             1",/
so N2 is not in extended P-space (hereafter, always assume that 
ext.P-space is considered w.r.t. the failed link).
However, as a second (or a further) step, when distance from N2 to N2 
itself is evaluated, then

/"D_opt(N2, N2) < D_opt(N2,S) + D_opt(S,N2) is indeed satisfied//
//     0 //1//             1 "/
So, finally "somehow" N2 becomes the part of the extended P-space.

To me, it's still not clear for the following reasons:
i) from an implementation point of view, why should I evaluate the 
distance from me, to myself (D_opt(N2,N2))? Isn't it an unnecessary step 
that an algorithm should avoid.
ii) again, from an implementation point of view, and also according to 
the algorithm proposed in RFC7490, if for each node (w.r.t. the failed 
link) we store only a binary (boolean) variable to indicate whether it 
is in the ext.P-space or not, then who guarantees that in the above 
example the final state of this boolean variable of N2 will be True. 
It's really typical (at least in usual programming languages ) that 
traveling all the nodes in the graph more times, then you definitely 
won't get the same order at each case.
So, what I want to tell here, that it could be the case that "D_opt(N2, 
N2) < D_opt(N2,S) + D_opt(S,N2)"  will be evaluated first an N2 becomes 
the part of the ext.P-space, but at the end of the loop, N2 won't be in 
the ext.P-space

What is your opinion about this?

Regards,
Levente

On 10/27/2015 06:31 PM, Pushpasis Sarkar wrote:
> 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.
> *[Pushpasis] I think you might have misunderstood it.. Ni is not a 
> single neighbor of S.. The term Ni in the above inequality stands for 
> all neighbors of S other than E (primary next hop).. Here is the text 
> once more..*
> *
> *
> "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.
> *So one possible value for Ni can be Y itself..  So now if you 
> substitute Y for Ni in the above inequality it satisfies the 
> inequality.. *
> *
> *
> *D_opt(Y, Y) < D_opt(Y,S) + D_opt(S,Y)*
> *      0                     1                     1*
> *
> *
> *However to make it more clear let me rename the Nodes Ni and Y in the 
> above diagram as N1 and N2. So the diagram now looks like.. *
> *
> *
> *  N2
> 2/ \
> N1--S--x--E
> |        /
> B       D
> \      /
>  \    /
>   \  /
>    A
> *
> *
> *
> *Ni = {N1, N2}*
> *
> *
> *Now with N2 as the candidate, *
> *
> *
> *substituting Ni = N1*
> *
> *
> *D_opt(N1, N2) < D_opt(N1,S) + D_opt(S,N2) is not satisfied*
> *                  2         1                          1*
> *
> *
> *However substituting Ni = N2*
> *
> *
> *D_opt(N2, N2) < D_opt(N2,S) + D_opt(S,N2) is indeed satisfied*
> *                  0          1                          1*
> *
> *
> *So N2 is in link-protecting Ext-P-Space of S, wrt S-E link.*
> *
> *
> *Essentially for Y to be in link-protected Extended P-Space(S, S-E) S 
> (or one of the neighbors of S other than E) should be able to reach Y 
> without taversing the S-E link.. The above inequality is satisfied by 
> substituting Ni as Y.*
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 28 Oct 2015 11:02:56 +0000

Hi Levente,

From: Levente Csikor <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 28, 2015 at 2:04 PM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[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

Dear Pushpasis,
I agree with you with the previous observations, except the following can not gracefully leave my mind :)

[Pushpasis]As per RFC 7490.. Ext-P space(S, S-E) is a union of P-space(S, S-E) and P-Space(all neighbors of S except E, S-E). In the example you have chosen Y (later renamed to N2) is in P-Space(S, S-E) though not in P-Space(N1, S-E). The inequality is a generalised version that fits other scenarios. Even though the example chosen does not seem to be a good one to demonstrate the use of this generalised inequality, the inequality still does work even with this example. :)

Tell me if I did not get your point, but according to your inequalities, it seems that N2 being evaluated at first gives an error, i.e.,

"D_opt(N1, N2) < D_opt(N1,S) + D_opt(S,N2) is not satisfied
    2              1             1",
so N2 is not in extended P-space (hereafter, always assume that ext.P-space is considered w.r.t. the failed link).
However, as a second (or a further) step, when distance from N2 to N2 itself is evaluated, then

"D_opt(N2, N2) < D_opt(N2,S) + D_opt(S,N2) is indeed satisfied
     0             1              1 "
So, finally "somehow" N2 becomes the part of the extended P-space.

To me, it's still not clear for the following reasons:
i) from an implementation point of view, why should I evaluate the distance from me, to myself (D_opt(N2,N2))? Isn't it an unnecessary step that an algorithm should avoid.
[Pushpasis]Like mentioned before an implementation needs to be generic enough to handle all kinds of the topology example. If you can suggest a better inequality I will be more than happy to accommodate it the document. Please let me know if you have a better inequality in your mind.

ii) again, from an implementation point of view, and also according to the algorithm proposed in RFC7490, if for each node (w.r.t. the failed link) we store only a binary (boolean) variable to indicate whether it is in the ext.P-space or not, then who guarantees that in the above example the final state of this boolean variable of N2 will be True. It's really typical (at least in usual programming languages ) that traveling all the nodes in the graph more times, then you definitely won't get the same order at each case.
So, what I want to tell here, that it could be the case that "D_opt(N2, N2) < D_opt(N2,S) + D_opt(S,N2)"  will be evaluated first an N2 becomes the part of the ext.P-space, but at the end of the loop, N2 won't be in the ext.P-space
[Pushpasis] What you are trying to discuss here is more of like implementation details. As a implementor I have implemented this for the company I work for and am sure can be implemented using any programming language. How to implement this should be outside the scope of this document. However still here is a high-level algorithm for your understanding.

For each node ‘X’ in the LSDB
-  Set X.InExtPSpace ==> FALSE
 - For each direct neighbor ’N’ in Neighbor-List
    - If D_opt(N, X) < (D_opt(N,S) + D_opt(S,X) then
       - Set X.InExtPspace ==> TRUE
       - Continue to next node in LSDB
  - EndFor
EndFor

What is your opinion about this?
[Pushpasis] Hope the above explanation helps clarifying things.

Thanks
-Pushpasis

Regards,
Levente

  N2
2/ \
N1--S--x--E
|        /
B       D
\      /
 \    /
  \  /
   A

Ni = {N1, N2}

substituting Ni = N1

---

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

I think the key thing here is that while the inequality

(i) D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,E) + D_opt(E,Y)

Is clearly correct. i.e. the path from N1 to Y is shorter than the path 
via S-E

Pushpasis inequality

(ii) D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y)

provides the same result since D_opt(S,Y) has two cases

1) the path from S to Y doesn't traverse S-E, in which case Y is clearly 
in extended P-space, since it is in fact in P-space, and the inequality 
will always be met, since the direct path from Ni to Y will always be 
shorter than the path via S, except in the case where the shortest path 
actually traverses S. But this doesn't matter since in that case there 
will always be another Ni (even if it is Y itself) for which this is not 
the case.  At least I THINK that is what Pushpasis is saying.

2) The path from S to Y DOES traverse S-E, in which case D_opt(S,Y) = 
D_opt(S,E) + D_opt(E,Y), and hence inequality (ii) reduces to inequality 
(i) as required.

However, I think the draft would benefit from some explanation of this.

     Mike

On 28/10/2015 11:02, Pushpasis Sarkar wrote:
> Hi Levente,
>
>
> From: Levente Csikor <[email-masked] <mailto:[email-masked]>>
> To: Pushpasis Sarkar <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[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
>
> Dear Pushpasis,
> *[Pushpasis]As per RFC 7490.. Ext-P space(S, S-E) is a union of 
> P-space(S, S-E) and P-Space(all neighbors of S except E, S-E). In the 
> example you have chosen Y (later renamed to N2) is in P-Space(S, S-E) 
> though not in P-Space(N1, S-E). The inequality is a generalised 
> version that fits other scenarios. Even though the example chosen does 
> not seem to be a good one to demonstrate the use of this generalised 
> inequality, the inequality still does work even with this example. :)*
>
> Tell me if I did not get your point, but according to your 
> inequalities, it seems that N2 being evaluated at first gives an 
> error, i.e.,
> /
> distance from me, to myself (D_opt(N2,N2))? Isn't it an unnecessary 
> step that an algorithm should avoid.
> *[Pushpasis]Like mentioned before an implementation needs to be 
> generic enough to handle all kinds of the topology example. If you can 
> suggest a better inequality I will be more than happy to accommodate 
> it the document. Please let me know if you have a better inequality in 
> your mind.*
>
> So, what I want to tell here, that it could be the case that 
> "D_opt(N2, N2) < D_opt(N2,S) + D_opt(S,N2)"  will be evaluated first 
> an N2 becomes the part of the ext.P-space, but at the end of the loop, 
> N2 won't be in the ext.P-space
> *[Pushpasis] What you are trying to discuss here is more of like 
> implementation details. As a implementor I have implemented this for 
> the company I work for and am sure can be implemented using any 
> programming language. How to implement this should be outside the 
> scope of this document. However still here is a high-level algorithm 
> for your understanding.*
> *
> *
> *For each node ‘X’ in the LSDB*
> *-  Set X.InExtPSpace ==> FALSE*
> * - For each direct neighbor ’N’ in Neighbor-List*
> *    - If D_opt(N, X) < (D_opt(N,S) + D_opt(S,X) then *
> * - Set X.InExtPspace ==> TRUE*
> *       - Continue to next node in LSDB*
> *  - EndFor*
> *EndFor*
>
>
> *[Pushpasis] Hope the above explanation helps clarifying things.*
> *
> *
> *Thanks*
> *-Pushpasis*
>
> Regards,
> Levente
>
>
>> 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.
>> direct neighbor of S, Ni, other than primary nexthop E, that 
>> satisfies the following condition.
>> *However to make it more clear let me rename the Nodes Ni and Y in 
>> the above diagram as N1 and N2. So the diagram now looks like.. *
>> *
>> *
>> *  N2
>> 2/ \
>> N1--S--x--E
>> |        /
>> B       D
>> \      /
>>  \    /
>>   \  /
>>    A
>> *
>> *
>> *
>> *Ni = {N1, N2}*
>> *
>> *

---

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

Hi Levente,

Here is the excerpt from RFC7490 that also gives a more refined version of the psuedocode I have provided earlier...

“

      /////////////////////////////////////////////////////////////////
      //
      // Calculate Extended P-space
      //
      // Note that the "strictly less than" operator is needed to
      // avoid ECMP issues.

      Compute_Extended_P_Space(fail_intf)
          foreach node y in network
              y.in_extended_P_space = false
              // Extend P-space to the P-spaces of all reachable
              // neighbors
              foreach interface intf in self
                  // Exclude failed interface, noting that
                  // the node reachable via that interface may be
                  // reachable via another interface (parallel path)
                  if (intf != fail_intf)
                      foreach neighbor n in intf.remote_node
                          // Apply RFC 5286 Inequality 1
                          if ( D_opt(n, y) <
                                  D_opt(n,self) + D_opt(self, y))
                              y.in_extended_P_space = true

“

Thanks
-Pushpasis

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 28, 2015 at 4:32 PM
To: Levente Csikor <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[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

---

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

Hi Mike and Levente,

The inequality for extended-P-space in this document is same as the one mentioned in section 5.3 of RFC7490. Here is the excerpt…

“

“

I don’t see why there will be any confusion.

Thanks
-Pushpasis

From: Mike Shand <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 28, 2015 at 5:26 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

Is clearly correct. i.e. the path from N1 to Y is shorter than the path via S-E

Pushpasis inequality

1) the path from S to Y doesn't traverse S-E, in which case Y is clearly in extended P-space, since it is in fact in P-space, and the inequality will always be met, since the direct path from Ni to Y will always be shorter than the path via S, except in the case where the shortest path actually traverses S. But this doesn't matter since in that case there will always be another Ni (even if it is Y itself) for which this is not the case.  At least I THINK that is what Pushpasis is saying.

2) The path from S to Y DOES traverse S-E, in which case D_opt(S,Y) = D_opt(S,E) + D_opt(E,Y), and hence inequality (ii) reduces to inequality (i) as required.

    Mike

Dear Pushpasis,

Thanks
-Pushpasis

Regards,
Levente

  N2
2/ \
N1--S--x--E
|        /
B       D
\      /
 \    /
  \  /
   A

Ni = {N1, N2}

substituting Ni = N1

---

From: Mike Shand <[email-masked]>
Date: Wed, 28 Oct 2015 13:23:40 +0000

I think this just goes to show how confusing the distance based 
definitions of this stuff can be! While I agree that an implementation 
may use those techniques, I find it MUCH simpler to understand using the 
traditional definitions.

     Mike

On 28/10/2015 12:47, Pushpasis Sarkar wrote:
> Hi Mike and Levente,
>
> The inequality for extended-P-space in this document is same as the 
> one mentioned in section 5.3 of RFC7490. Here is the excerpt…
>
> “
>                            *if ( D_opt(n, y) < D_opt(n,self) + D_opt(self, y)) 
> y.in_extended_P_space = true*
> “
>
> From: Mike Shand <[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]>>, Levente Csikor <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> 1) the path from S to Y doesn't traverse S-E, in which case Y is 
> clearly in extended P-space, since it is in fact in P-space, and the 
> inequality will always be met, since the direct path from Ni to Y will 
> always be shorter than the path via S, except in the case where the 
> shortest path actually traverses S. But this doesn't matter since in 
> that case there will always be another Ni (even if it is Y itself) for 
> which this is not the case.  At least I THINK that is what Pushpasis 
> is saying.
>
> D_opt(S,E) + D_opt(E,Y), and hence inequality (ii) reduces to 
> inequality (i) as required.
>
>> version that fits other scenarios. Even though the example chosen 
>> does not seem to be a good one to demonstrate the use of this 
>> generalised inequality, the inequality still does work even with this 
>> example. :)*
>>
>> generic enough to handle all kinds of the topology example. If you 
>> can suggest a better inequality I will be more than happy 
>> to accommodate it the document. Please let me know if you have a 
>> better inequality in your mind.*
>>
>> ii) again, from an implementation point of view, and also according 
>> to the algorithm proposed in RFC7490, if for each node (w.r.t. the 
>> failed link) we store only a binary (boolean) variable to indicate 
>> whether it is in the ext.P-space or not, then who guarantees that in 
>> the above example the final state of this boolean variable of N2 will 
>> be True. It's really typical (at least in usual programming languages 
>> ) that traveling all the nodes in the graph more times, then you 
>> definitely won't get the same order at each case.
>> an N2 becomes the part of the ext.P-space, but at the end of the 
>> loop, N2 won't be in the ext.P-space
>> *- EndFor*
>>> single neighbor of S.. The term Ni in the above inequality stands 
>>> for all neighbors of S other than E (primary next hop).. Here is the 
>>> text once more..*
>>> *
>>> *
>>> *0                        1          1*
>>> *Essentially for Y to be in link-protected Extended P-Space(S, S-E) 
>>> S (or one of the neighbors of S other than E) should be able to 
>>> reach Y without taversing the S-E link.. The above inequality is 
>>> satisfied by substituting Ni as Y.*
>>>
>>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Oct 2015 16:11:11 +0000

+1

Stewart

On 28/10/2015 13:23, Mike Shand wrote:
> may use those techniques, I find it MUCH simpler to understand using 
> the traditional definitions.
>
>     Mike
>
>> From: Mike Shand <[email-masked]>
>> <mailto:[email-masked]>>, "[email-masked] 
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> inequality will always be met, since the direct path from Ni to Y 
>> will always be shorter than the path via S, except in the case where 
>> the shortest path actually traverses S. But this doesn't matter since 
>> in that case there will always be another Ni (even if it is Y itself) 
>> for which this is not the case.  At least I THINK that is what 
>> Pushpasis is saying.
>>
>>> I agree with you with the previous observations, except the 
>>> following can not gracefully leave my mind :)
>>>
>>> P-space(S, S-E) and P-Space(all neighbors of S except E, S-E). In 
>>> the example you have chosen Y (later renamed to N2) is in P-Space(S, 
>>> S-E) though not in P-Space(N1, S-E). The inequality is a generalised 
>>> generalised inequality, the inequality still does work even with 
>>> this example. :)*
>>>
>>> the above example the final state of this boolean variable of N2 
>>> will be True. It's really typical (at least in usual programming 
>>> languages ) that traveling all the nodes in the graph more times, 
>>> then you definitely won't get the same order at each case.
>>>> for all neighbors of S other than E (primary next hop).. Here is 
>>>> the text once more..*
>>>> *
>>>> *
>>>> *2                         1            1*
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

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

Hi Mike and Levente,

Does that mean you want these inequalities removed from this document? Or do you want me to add more text?

If the later, it will be great if you can suggest some text for clarifying these.

Thanks
-Pushpasis

From: Mike Shand <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 28, 2015 at 6:53 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

I think this just goes to show how confusing the distance based definitions of this stuff can be! While I agree that an implementation may use those techniques, I find it MUCH simpler to understand using the traditional definitions.

    Mike

“

“

Thanks
-Pushpasis

From: Mike Shand <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 28, 2015 at 5:26 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

Pushpasis inequality

    Mike

Dear Pushpasis,

Thanks
-Pushpasis

Regards,
Levente

  N2
2/ \
N1--S--x--E
|        /
B       D
\      /
 \    /
  \  /
   A

Ni = {N1, N2}

substituting Ni = N1

---

From: Mike Shand <[email-masked]>
Date: Thu, 29 Oct 2015 09:32:20 +0000

What we have done in the past is use the traditional descriptions in the 
body of the text, and then added a metric based version for those who 
like that kind of thing as a separate section. c.f. RFC 7490

This seems to satisfy both ways of thinking about the problem.

Does that seem reasonable?

     Mike

---

From: Levente Csikor <[email-masked]>
Date: Sat, 31 Oct 2015 11:21:18 +0100

Hi Pushpasis,
Thanks, I now understand it more clearly, and thanks to Mike for his 
distance-based examples.
Now, I see why are those two inequalities are the same. However, as you 
saw it raised questions and wasn't that straightforward at the first time.
That's why I could better understand the distance metrics for extended 
P-space if the failed link itself was also in the inequality.

In the document, there would be good if Mike's examples were shown, 
i.e., the first (D_opt) inequality will be the one with the failed link, 
then as a further explanation could come Mike's example, which clearly 
shows how the inequality becomes easier with the original inequality.

Regards,
Levente

On 10/29/2015 10:32 AM, Mike Shand wrote:
> What we have done in the past is use the traditional descriptions in 
> the body of the text, and then added a metric based version for those 
> who like that kind of thing as a separate section. c.f. RFC 7490
>
>> Does that mean you want these inequalities removed from this 
>> document? Or do you want me to add more text?
>>
>> definitions of this stuff can be! While I agree that an 
>> implementation may use those techniques, I find it MUCH simpler to 
>> understand using the traditional definitions.
>>
>>     Mike
>>
>>> the shortest path actually traverses S. But this doesn't matter 
>>> since in that case there will always be another Ni (even if it is Y 
>>> itself) for which this is not the case.  At least I THINK that is 
>>> what Pushpasis is saying.
>>>
>>> 2) The path from S to Y DOES traverse S-E, in which case D_opt(S,Y) 
>>> = D_opt(S,E) + D_opt(E,Y), and hence inequality (ii) reduces to 
>>>> the example you have chosen Y (later renamed to N2) is in 
>>>> P-Space(S, S-E) though not in P-Space(N1, S-E). The inequality is a 
>>>> generalised version that fits other scenarios. Even though the 
>>>> example chosen does not seem to be a good one to demonstrate the 
>>>> use of this generalised inequality, the inequality still does work 
>>>> even with this example. :)*
>>>>
>>>> whether it is in the ext.P-space or not, then who guarantees that 
>>>> in the above example the final state of this boolean variable of N2 
>>>> "D_opt(N2, N2) < D_opt(N2,S) + D_opt(S,N2)"  will be evaluated 
>>>> first an N2 becomes the part of the ext.P-space, but at the end of 
>>>> the loop, N2 won't be in the ext.P-space
>>>> implementation details. As a implementor I have implemented this 
>>>> for the company I work for and am sure can be implemented using any 
>>>> scope of this document. However still here is a high-level 
>>>> algorithm for your understanding.*
>>>> *
>>>> *
>>>>> *Essentially for Y to be in link-protected Extended P-Space(S, 
>>>>> S-E) S (or one of the neighbors of S other than E) should be able 
>>>>> to reach Y without taversing the S-E link.. The above inequality 
>>>>> is satisfied by substituting Ni as Y.*
>>>>>
>>>>
>>>
>>
>