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

Stewart Bryant <> Wed, 07 December 2016 11:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FD2F129D2C; Wed, 7 Dec 2016 03:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7q1RLfzVV8uj; Wed, 7 Dec 2016 03:04:10 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B4A4129D56; Wed, 7 Dec 2016 03:03:38 -0800 (PST)
Received: by with SMTP id f82so160844819wmf.1; Wed, 07 Dec 2016 03:03:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=y7n9ysBKxnHs3Nm1KTwwc1Vx6D2eYDyz8pzd7kwR+Xo=; b=fpVtUqcrgN8nhLaZEwdn8yXDbWY7AU2co1nKT+iLhz1ZtLrAt5lXnK7Qjk5AFycsKg o3aFwPUi2I5r9e86OdhDHEB9QZef4qEtL/O6jN2i0T4m8EZI+Fti4b3425bq3tRPM5Ij Jh0T+wZCmM32dGoOeC0CYXJInbk4VEY9r2zX/6Cha+0T0Qd/2IVe+v7g0y2k/GdVhdEO 0wKtTuTtKgAe6KpLSwqOTHCO3JYaZAfZ3VH8D4srkkxUdVEbgG79Rz8NukEsPYxi14cS DN+RMQQMRiA1WED/Gnnn5FSWLsl9E4h90oOMYkmsbZ8S4ipC/rIWWby4ggDDHqsdJcUq +OKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=y7n9ysBKxnHs3Nm1KTwwc1Vx6D2eYDyz8pzd7kwR+Xo=; b=Lto+dHwFGdHvU721dFVo4CKTwJk0lEPttuABWsrb620rJ+sUVRRMLiMjJQfDVYFekF 0+TwP7jLIFqQ85R8aVrupcBsJte0Vl8LVIlwhnYo0JU2i+qt3f4Sb3NSynDKbQRHWZfk VZ0egDIdp4IOCyKFk7NWSYPXWoUIDP2KdiuIMKT7qu8ZPzvE3tOAmKs+0TqDhqt5lEd/ YXmxL2GyL2At0gYl+P+C7DTNT+V0xtHY/0Op/lfjMT1rkfPMWnOouwANUIW6VIBrn29V z55+wxLBm1VGcsAZWd5UMTjv4P92zFVEIUKMgzbTdqpy1MZf45uRkjDabNh7gSsBjDOr l+xg==
X-Gm-Message-State: AKaTC02vm/SFfU0JNfCviKNC6YtkkcyIuxABT+IcqNKJACZqWWxiII+yHyEQ4MsMsEzfYQ==
X-Received: by with SMTP id j75mr1188233wmf.14.1481108616713; Wed, 07 Dec 2016 03:03:36 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id r138sm9043941wme.9.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2016 03:03:36 -0800 (PST)
To: Santosh Esale <>, "" <>, "" <>
References: <>
From: Stewart Bryant <>
Message-ID: <>
Date: Wed, 07 Dec 2016 11:03:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [mpls] Fast Reroute for Node Protection in LDP-based LSPs
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Dec 2016 11:04:15 -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