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 :) 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
