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

[Robert Raszuk <[e-mail]>]

Dear Stewart,

On Wed, Dec 7, 2016 at 12:03 PM, Stewart Bryant <[e-mail]>
wrote:

Using a RSVP-TE tunnel to provide an LDP FRR solution is well
> ​
> known and deployed.


​That may or may not be the case. Yes we (well some of us) have been
involved for decades in making those solutions to somehow work in a very
very limited real production scale (if at all). One hop LSPs for FRR have
been sporadically deployed in very few cases. Yet the overhead associated
with such endeavor is significant especially in OPEX cost and training of
internal teams to maintain it.

Those who just focus on vendor's world may not always realize this. What
works on the ppt, rfc or patent turns often very costly in real
deployments.

RSVP-TE extensions or LDP are both redundant and frankly unnecessary
protocols and the sooner we get rid of those the better. They bring no
value and to all of us who have been involved in defining and deploying
those this should be of no surprise. It is only those who has been heavily
infected by various marketing forces think overwise.

Therefor I do object using terms of "well known or deployed" as any form of
judgement of new work in any form. Even so without real data on how well
know or wide deployed that would be. And even if it is deployed in few
places this is no reason not to recommend improvements even if those would
result in innovative proposals.

As to your comments on speed and compute costs let's do realize that what
have been a factor 5 or 10 years ago where everything needed to run on weak
REs today computation is done outside of network elements. And while we are
not there in mass scale the number of modern vendors which I am testing do
have very significant innovations in control plane computing paradigms ..
something which we never imagined x years back.

Yes your point may very well be valid that we will still find nits to work
and fix down the road, but those again are not in any rationale sense to
stop the work or adjust it to status quo. It is like you would still prefer
to cross Atlantic using Titanic as opposed to kill 380 or 787s just because
it is no a ship.

Bottom line .. I highly support TI-LFA even if for some vendors it means
departure from their years of selling RSVP/LDP mantra.

​Yours,
Robert.​



> 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
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>