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]
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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
