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

[Mike Shand <[e-mail]>]

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


On 28/10/2015 09:11, Levente Csikor wrote:
> 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:
>> 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 <[e-mail]>
>>> Date: Tuesday, October 27, 2015 at 10:35 PM
>>> To: Levente Csikor <[e-mail]>, "[e-mail] 
>>> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, 
>>> Pushpasis Sarkar <[e-mail] <mailto:[e-mail]>>
>>> 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,"[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]://www.ietf.org/mailman/listinfo/rtgwg
>>>>
>>>
>>
>