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