Subject: Fast Reroute for Node Protection in LDP-based LSPs

From: Santosh Esale <[email-masked]>
Date: Mon, 5 Dec 2016 19:59:28 +0000

Hello Everyone,
                           We have presented the draft - draft-esale-mpls-ldp-node-frr – in
MPLS working group in three IETF meetings including the latest one at Seul.
However, as the draft is of interest to routing working too, we are initiating this
thread to solicit feedbacks from the routing working group. Please let us know
your comments.

Presentations -
https://www.ietf.org/proceedings/93/slides/slides-93-mpls-3.pdf
https://www.ietf.org/proceedings/94/slides/slides-94-mpls-3.pptx
https://www.ietf.org/proceedings/97/slides/slides-97-mpls-08-ti-frr-ietf-97-00.pptx

Thanks,
Santosh (on behalf of authors)

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 6 Dec 2016 12:17:34 +0100

hi santosh,

just curious why the proposed solution is constrained to only use LDP ?

IMO what you have suggested here would just fit nicely for protecting
segment-routing node labels as well. segment routing node-labels are
"calculated" in a similar fashion than LDP labels as such my guess would
be that this solution applies to SR node labels as well.

suggest to generalize it to:
"Fast Reroute for Node Protection in hop-by-hop based LSPs"

thanks,

/hannes

On 12/5/16 20:59, Santosh Esale wrote:
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Santosh Esale <[email-masked]>
Date: Tue, 6 Dec 2016 22:55:45 +0000

Hi Hannes,
          Good point! We will generalize the solution to cover
segment-routing (SR) too in the next - 05 revision.

Thanks,
Santosh

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 7 Dec 2016 09:30:21 +0000

> On Dec 6, 2016, at 11:55 PM, Santosh Esale <[email-masked]> wrote:
> 
> Hi Hannes,

I don’t think your solution brings anything better than what already covered in ti-lfa draft for segment-routing. See draft-francois-rtgwg-segment-routing-ti-lfa-02.

s.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 7 Dec 2016 11:03:34 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Dec 2016 02:00:56 +0100

Dear Stewart,

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

> ​
> 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
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 8 Dec 2016 11:50:42 +0000

On 08/12/2016 01:00, Robert Raszuk wrote:
> Dear Stewart,
>
> On Wed, Dec 7, 2016 at 12:03 PM, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>

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.

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

>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>
>

---

From: Santosh Esale <[email-masked]>
Date: Fri, 9 Dec 2016 19:15:45 +0000

Hi Stefano,
           The main purpose of the solution is to provide
topology independent local protection using RSVP-TE in widely
deployed LDP based MPLS networks. Link protection is already
deployed using manually configured RSVP-TE one-hop LSPs. This
draft addresses node protection.

Now, the solution can also be used to protect segment routing
hop-by-hop node segments and we would add a note about it.
Of course, the other solution that you mentioned may fit
segment-routing too.

Thanks,
Santosh
On 12/7/16, 1:30 AM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:

>I don’t think your solution brings anything better than what already
>covered in ti-lfa draft for segment-routing. See
>draft-francois-rtgwg-segment-routing-ti-lfa-02.
>
>s.
>
>
>> 
>> Thanks,
>> Santosh
>> 
>>>>https://www.ietf.org/proceedings/97/slides/slides-97-mpls-08-ti-frr-iet
>>>>f-
>>>> 97-00.pptx
>>>> 
>>>> Thanks,

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 12 Dec 2016 11:22:04 +0000

> On Dec 9, 2016, at 8:15 PM, Santosh Esale <[email-masked]> wrote:
> 
> Hi Stefano,

My point is that if you have SR in your network, it doesn’t make much sense to use an RSVP or LDP based solution.

Thanks.
s.