Using a RSVP-TE tunnel to provide an LDP FRR solution is well known and deployed. The specific case of node protection is called out in Figure 3 of RFC4090. I am surprised that the complete solution is not documented, but if that is the case it should be, with proper attribution.
Getting the next next hop label set is problematic, the standard solution needing a targetted LDP session to each NNH. There was a proposal to address this proposed draft-shen-mpls-ldp-nnhop-label-02 which is worth examining. The method of finding the next next hop is well documented for example in RFC6981 and these should be referenced at least in the development phase of this work to allow cross checking. "The discovery of the next next-hop (depending on an implementation) may not involve any additional SPF, above and beyond what would be needed by ISIS/OSPF anyway, as the next next- hop, just like the next-hop, is a by-product of SPF computation." That is what I thought when I started work on IPFRR, but it is very much dependent on the speed and memory optimizations used and because this information is not needed for normal operation it is often discarded. " If for a given <LSP, PLR, N> triplet the node protected by the PLR is an Area Border Router (ABR), then the PLR and the next next-hop may end up in different IGP areas (this could happen when an LSP traversing the PLR and the protected node does not terminate in the same IGP area as the PLR). In this situation the PLR may not be able to determine the next next-hop from either its Traffic Engineering database or Link State database, and thus may not be able to use the next next-hop as the MPT. In this scenario the PLR uses an "alternative" ABR as the MPT, where an alternative ABR is defined as follows. For a given LSP that traverses the PLR and the (protected) ABR, an alternative ABR is defined as any ABR that advertises into PLR's own IGP area reachability to the FEC associated with the LSP. Note that even if a PLR protects an ABR, for some of the LSPs traversing the PLR and the ABR, the next next-hops may be in the same IGP area as the PLR, in which case these next next-hops act as MPTs for these LSPs. Note that even if the protected node is not an ABR, if an LSP traversing the PLR and the protected node does not terminate in the same IGP area as the PLR, then for this LSP the PLR MAY use an alternative ABR (as defined above), rather than the next next-hop as the MPT. " In a general solution, I would like to see this written so that it is OSPF/ISIS agnostic. This an example of the general case of multi-homed prefixes. Addressing MHP requires that egress be forced to prevent packet looping. "4. Constructing Bypass LSPs" There is quite a lot of work on the calculation of node avoiding paths that you should look at, for example RFC6981 to verify that nothing has been forgotten. " 5. Obtaining Label Mapping from MPT" Again it is worth looking at existing work in this space. "6. Forwarding Considerations When a PLR detects failure of the protected node then rather than swapping an incoming label with a label that the PLR received from the protected node, the PLR swap the incoming label with the label that the PLR receives from the MPT, and then pushes the label associated with the bypass LSP to that MPT. To minimize micro-loop during the IGP global convergence PLR may continue to use the bypass LSP during network convergence by adding small delay before switching to a new path." It is nowhere as simple as that. Again there is a lot of writing on the subject. For example RFC5715. Sure you need to keep the repair path in place and using an RSVP-TE tunnel means that you will not suffer the problem of microlooping along that tunnel. What you need to be clear about is that you are not protecting against any other microloop, for example between hop PLR-1 and PLR-2. - Stewart _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
