Thanks
-Pushpasis
*From:*Levente Csikor [mailto:[email protected]]
*Sent:* Wednesday, October 09, 2013 8:21 PM
*To:* Pushpasis Sarkar
*Cc:* [email protected]; Chris Bowers
*Subject:* Re: Request for review -
draft-psarkar-rtgwg-rlfa-node-protection-01.txt
To calculate, which nodes are in the Q-space I've just looked for
nodes for which your distance function in Fig.2. applies.
From an industrial/implementation point of view, I have no exact claim
how the calculations should be made.
Furthermore, assuming that only link failures are considered in a unit
cost network (where every link has the same unit cost), then rLFA
provides 100% failure coverage. Note that in this case the minimal
graph topological requirement is 2-edge-connectivity. That's why I
said that theoretical investigation of the rLFA node-protecting
failure coverage needs 2-node-connected networks to suppose that may
100% node-protection can be reached.
On 10/09/2013 04:28 PM, Pushpasis Sarkar wrote:
Hi Levente,
"I did not consider any possible way of determining PQ-nodes, only
used the description of P and Q spaces from the original draft,
and from my research on this topic, where every kind of spaces
were defined in cost terms to easily analyze the network
theoretically."
The original Q-space definition is...
"the set of routers which can reach the primary neighbor E can
without traversing the link (S-E) being protected"
What will the definition for Q-space definition in this case? Do
you mean...
" the set of routers than can reach the primary neighbor E without
traversing any links originating from E"? That will leave no
routers in the set.. Right?
What makes sense is "the set of routers that can reach destination
without traversing any links originating/attached to E".... For
doing that we will have two options
1.RSPF rooted on the destination (will be very expensive if we
have to do that for every destination node in the network).. OR
2.FSPF rooted on the PQ-node and check if primary neighbor E is on
the SPF path from PQ-node to destination.. This is what is
specified in our draft.. Assuming number of PQ-nodes are far less
than number of nodes in the network this approach looked more
feasible. Also now we are able to collect full path attributes for
RLFA backup paths for LFA-manageability. Also RLFA does not
attempt to provide 100% coverage. So like already said,
implementations can decide to only consider upto a certain number
of PQ-nodes to be considered in the whole network to limit the
number of extra FSPFs to be computed.
Thanks
-Pushpasis
*From:*Levente Csikor [mailto:[email protected]]
*Sent:* Wednesday, October 09, 2013 5:17 PM
*To:* Pushpasis Sarkar
*Cc:* [email protected] <mailto:[email protected]>; Chris Bowers
*Subject:* Re: Request for review -
draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Dear Pushpasis,
thanks for your comments.
For reactions see mine inline:
On 10/09/2013 12:49 PM, Pushpasis Sarkar wrote:
Hi Levente,
Please find few comments inline...
Thanks
-Pushpasis
-----Original Message-----
From: Levente Csikor [mailto:[email protected]]
Sent: Wednesday, October 09, 2013 2:00 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: Request for review -
draft-psarkar-rtgwg-rlfa-node-protection-01.txt
Dear All,
I also support to work more on the node protection draft
first, before merging it with "basic rLFA spec", because of
various reasons:
First, I think it would be almost a good approach to show how
node-protecting remote LFA works on the same, or almost the
same sample network topology used in the basic rLFA spec., but
for easier and more comprehensive understanding, a bit more
complex but still simple example should be given. IMHO, in the
basic rLFA spec. it is a bit confusing that node E is
considered as a destination and this node is the next-hop as
well, since the important parts of the different roles are not
dissevering enough. Because of this, the similar example in
node prot spec. is also not straightforward:
*[Pushpasis] If you see Table 1,2, and 3 in
draft-psarkar-rtgwg-rlfa-node-protection-01 we have specified
the destinations E, F (and their corresponding RLFA backup
paths explicitly), that will be affected by node-failure of E.
Also the destination G has been included which will still be
reachable in the case of node-failure of E. Perhaps basic RLFA
spec can also include such kind of illustrations*
**Yeah, I know and there is also the entry in the back-up path
column for G, but here, I wanted to emphasized that the
connectedness of the network does not remain any other
opportunities to be considered.
In other words, if there were an additional node between F and G,
say H, and nodes E-D-G-H-F would also form a 5-cycle, then all
your claims will remain valid, since C's shortest path to F won't
avoid the failed node E, but the graph-topological requirements
would be not so confusing (maybe only for me :) , but when I
analyze a network to calculate the rLFA protection coverage, then
I always assume this basic graph topological property to easily
derive the level of protection (in percent, for example) of the
possible attainable 100%).
"In the event of the node-failure on primary nexthop E, the
alternate path from Remote-LFA nexthop C to E and F also
becomes unavailable."
*[Pushpasis] That is exactly we are also saying in this
draft(I mean draft-psarkar-rtgwg-rlfa-node-protection-01).. If
any destination takes the shortest-path segment C...E that
will not have node-protection using C as the PQ node, because
C is going to forward the traffic to E anyhow. In Table 2 we
see that the path segment C->D->E is included in the shortest
path from C to E and F. That is why in case of node-failure of
E, E and F cannot provide node-protection*
**It was a quote from the draft, so it is really the fact that you
are saying :)
According to the well-known last-hop problem, it is obvious
that if the destination (in the first case: node E) goes down,
then it cannot be protected. Moreover, since the example
network topologyis not 2-node-connected, it is obvious again
that the node F, which can be accessed only via node E, then
the failure of node E infers that the node F can be never reached.
To (re)solve this issue, I suggest to use another network (in
the basic rLFA spec. as well), which could be the following
(all link costs are unit costs):
A----------B---------C
| | / |
| | / |
| | / |
F G / H
| | / |
| | / |
| | / |
D----------E---------S
In this case, assuming that source node S wants to send a
packet to node D, the next-hop of S is node E.
- Link protecting case: If link(s,e) fails, then P-space of
node S regarding to the failed link, would consist of node
H,C,B and A, whilst the Q-space of D would consist all nodes
except S and H. In this case, the PQ-nodes, as the possible
repair tunnel endpoints, are node A,B and C.
- Node protecting case: However, if node E itself fails,
then the P-space of S would not alter, but the Q-space of D
would only contain node F and A resulting that only node A is
present in the set of PQ-nodes.
*[Pushpasis] Can you elaborate on the method you used for
deriving the PQ-nodes A and F here... Seems to me like you are
doing a RSPF rooted on destination D and then pruning all
links originating from E... I think Chris Bowers has already
pointed on a different thread that while best way to guarantee
node-protection is to run a RSPF rooted on each destination,
we cannot afford to do so in reality... It will be much more
feasible to run FSPF on fewer PQ-nodes as specified in our
draft..*
**I did not consider any possible way of determining PQ-nodes,
only used the description of P and Q spaces from the original
draft, and from my research on this topic, where every kind of
spaces were defined in cost terms to easily analyze the network
theoretically.
**
*Also, the method specified by our draft also finds A as the
node-protecting PQ-node, becoz the draft suggest to find the
shortest-path from the PQ-nodes (C, B, and A) to destination
D. Only the SPF path from A does not go through E, so only A
will provide node-protection for D.*
I think that this network also shows the different between the
node protection and link protection, but in a more
comprehensive manner. And it also demonstrates the fact
mentioned in Figure 2 that for node-protecting rLFA, only the
Q-spaces should be checked with those distance functions.
Moreover, if we assume that in the example network above,
there is a link (A,E) and node E itself failed again, than
PQ-space would be and empty set meaning that this case cannot
be protected.
*[Pushpasis] True. Our draft will also pick A->E->D as the SPF
from A to D in that case and disqualify A as node-protecting
PQ-node. In reality too there is no feasible path in this case
till A re-converges after learning E's node-failure*
**I know that it is true, I just wanted to say that by this
network, the case of absence of node protection could be
demonstrated easily assuming that the main example was the network
described above.
Second, it would be better in the draft if the questions about
"how difficult or impossible to obtain those distances" would
be clearly stated in a bullet point list:
For example:
- Q-space can be obtained by rSPF calculated at destination
node D
- P-space can be obtained through SPF calculation at source
node S and its 1-hop neighbor.
- SPF at a PQ-node is impossible or if not what extensions
should be implemented (actually, IMHO, this is the one, which
is not clear enough)
*[Pushpasis] The first two should really be addressed in the
original RLFA draft. Chris has already written to the authors
on this mailing list with suggesting text for the draft. The
third one is no different than standard SPF we need for
RFC5286 implementation.. only difference being that it is
rooted on PQ-nodes in case of RLFA... It is up to individual
implementations to come up with ways to constraint those to a
limit. *
**Thanks
Third, according to the Targeted-LDP discussion, which is
about the fact that if some node do not support TLDP, then how
can be the inner MPLS label obtained from the PQ-node; I think
that if we want remote LFA protection then the nodes MUST
implement/support this feature, because without this the
protection cannot be guaranteed. For me, it is similar to a
hypothetic case for example of Not-via, where if the router do
not support Not-via, then it cannot be used. Or isn't it so
simple?
*[Pushpasis] Again this is more related to original RLFA
draft. I will prefer the corresponding authors to address this
point **J*
**Thanks
Please comment my observations, in order to help me and may
others as well to understand every aspects and little pieces
of remote LFA specifications.
Best Regards,
Levente Csikor
Thanks,
Levente Csikor
