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

[Mike Shand <[e-mail]>]

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

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

> 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.
>
> 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
>
>
> 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!
>
>
>
> 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,"[e-mail]"  <[e-mail]>  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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtgwg
>