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

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 14 Oct 2015 09:51:19 +0000

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]" <[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
>

---

From: Levente Csikor <[email-masked]>
Date: Tue, 27 Oct 2015 16:56:56 +0100

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.

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.

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.

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.

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.

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:
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Mike Shand <[email-masked]>
Date: Tue, 27 Oct 2015 17:05:34 +0000

Levente,

     Some good points that I missed in my review.

     Mike

On 27/10/2015 15:56, Levente Csikor wrote:
> And later the term primary node also rises the question whether it 
> means next-hop, or something else.
Next-hop is the conventional term

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

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

> "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,..."
> 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.
> "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.*"

Agreed. It should reference E. i.e. the Q-space of E w.r.t to S-E
>
>
> 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:
> node should not be on any of the shortest paths from the PQ-node to 
> the given destination."
>
> 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.
> 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!
>> 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: