Re: [mpls] Fast Reroute for Node Protection in LDP-based LSPs

[Stewart Bryant <[e-mail]>]

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