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]; 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
