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 protected] <mailto:[email protected]>>
Date: Tuesday, October 27, 2015 at 10:35 PM
To: Levente Csikor <[email protected] <mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, Pushpasis Sarkar <[email protected]
<mailto:[email protected]>>
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 protected]" <[email protected]>
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 protected]https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
