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

[Stewart Bryant <[e-mail]>]

On 08/12/2016 01:00, Robert Raszuk wrote:
> Dear Stewart,
>
> On Wed, Dec 7, 2016 at 12:03 PM, Stewart Bryant 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Using a RSVP-TE tunnel to provide an LDP FRR solution is well
>     ​
>     known and deployed. 
>

I was not particularly advocating this, indeed as you know I have spent 
many years looking at alternatives. Perhaps I misread the draft, we are 
discussing, but I read the draft  and saw the presentation at IETF97 and 
the draft seems to be proposing this very idea. I was trying to give it 
its proper context.

That said, it maybe that by using an appropriate mix of modern 
distributed and centralized path computation the deployment issues that 
concern you become addressed.

>
> ​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.

That is a much wider discussion.

My reading of your statement is that you are proposing the deprecation 
of RSVP-TE and LDP. If that is case, then that is a much wider and 
deeper discussion for the MPLS WG.

>
> 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.

Indeed, there are many innovations that can be applied to FRR. My point 
to the authors was to look at the work that has been published in the 
IETF and build on it.

>
> 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.

I seem to remember proposing splitting compute from routers in the 
generation being designed 17 years ago and using best in class computing 
systems rather than compute power that would fit on a blade. The idea 
was not acceptable then. Every idea has to live in it's own time. 
However going forward what is needed is a mixture of both distributed, 
autonomous operation and remote compute operation, and I don't think it 
is yet clear what the structure of the design needs to look like.

>
> 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.

I am not saying that. I think you need to re-read what I have written.

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

I am not arguing against TI-LFA in this thread, although I do have 
concerns about some aspects of that work, which I am sure we will 
discuss at some point.

An approach that I think might be reasonable, and I get the impression 
that this is where the authors are headed, is to look at how to do node 
repairs in a repair technology independent way. Whether one implements 
the repair by a explicit hard path, or a soft path, and how you set up 
that path is independent of this calculation. However I would hope that 
the draft would build upon what we have already published rather than 
start from scratch.

- Stewart


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