Subject: [mpls] draft-mtaillon-mpls-summary-frr-rsvpte

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Wed, 6 Jul 2016 03:05:20 +0000

Hi all,

During IETF95, we received some feedback on whether the option of pre-establishing of backup LSPs prior to the failure was considered. We’ve done some comparison of this approach versus RSVP-TE summary FRR proposed in the draft “draft-mtaillon-mpls-summary-frr-rsvpte” and summarized some pros/cons below. Given the points below, and wide deployment of RFC4090 FRR by multiple vendors, the author(s) think Summary FRR provides a better approach to proceed. Let us know if you have further feedback.

A. Pre-establishing backup LSP state over bypass prior to failure

PROs:

·         Less work needs to be done post failure – specifically related to establishing the backup LSP

·         The MP/PLR still needs to perform cleanup work after failure/local reroute for the affected protected LSP state

CONs:

·         There are (at least — see below) double the amount of soft states that the PLR and MP have to host and maintain in steady state

·         A node (MP) may host multiple backup LSP soft-states established by multiple upstream (PLRs) nodes - e.g. an upstream PLR may establish an NHOP backup session state terminating on a node MP, and the upstream-upstream PLR may also establish an NNHOP backup session terminating on the same node MP. The node MP cannot predict which of the 2 will carry the protected traffic until the failure occurs and will have to maintain the soft-state sessions of all backup LSPs signaled by upstream PLRs.

·         The MP and PLR needs to handle cases when either working or backup or both session(s) go down.  For example:

·         The PLR may need to duplicate Path/PathTear sent downstream (on both primary/bypass LSPs), and MP will need to duplicate Resv/ResvTear messages sent upstream

·         There are specific provisions in RFC4090 to for handling error messages by the MP and PLR during/after the failure/local repair for facility backup case -- for example, RFC4090 section 7.2. Such behavior(s) will need to be changed to addressed the pre-established LSP backup case.

·         The MP/PLR will still need to perform cleanup the primary session(s) post failure promptly. Delay(s) in doing so, will cause states to further quadruple as new protected session(s)/LSPs get signaled (possibly through the same MP/PLR pair)

·         In a sense, pre-establishing backup states resembles 1-to-1 backup/detour method in rf4090 which does not have wide deployments – usually attributed to worse scale than facility backup method

B. RSVP-TE Summary bypass FRR

PROs:

·         Does not need to maintain double states at PLR/MP in steady state prior to failure

·         Most of the work/association is done prior to the failure. Minimal work done post failure.

·         Message signaling is on per group of LSPs (as opposed on per LSP) – minimizes the number of messages exchanged between PLR and MP

·         No divergence from RFC4090 with respect to error handling by MP/PLR prior, during or after local reroute

CONs:

·         Post failure, the PLR and MP will need to process implicit Path and RESV on the group of associated sessions and generate the respective Path/RESV (that include the changes) to be sent downstream/upstream of MP/PLR.

·         Support for new extensions proposed in “draft-mtaillon-mpls-summary-frr-rsvpte”

Regards,

Tarek and co-author(s)