Network Working Group J. Jeganathan
Internet-Draft H. Gredler
Intended status: Standards Track Y. Shen
Juniper Networks
Nov 03, 2013

RSVP-TE LSP egress fast-protection
draft-minto-rsvp-lsp-egress-fast-protection-03

Abstract

RFC4090 defines a fast reroute mechanism for locally repairing an RSVP-TE LSP in the order of 10s of milliseconds, in the event of a downstream link or node failure. However, this mechanism does not provide node protection for LSP egress nodes, even when an alternate egress node (a backup egress) is available that could carry the traffic to its ultimate destination. This document addresses this scenario and describes how to provide egress protection by establishing a bypass LSP from the penultimate-hop node of a LSP to the backup egress node. The methods described in this document enable local repair in the order of 10s of milliseconds, in the event of the egress node failure. These methods are only applicable if traffic carried by the LSP can be rerouted to its ultimate destination by the backup egress node.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

This document describes procedures for providing fast protection for RSVP-TE LSPs in case of the egress node failure. Such protection can only be provided when an alternate egress node exists that can carry the traffic destined for the protected egress to its ultimate destination. The primary egress node of an LSP (the protected egress) terminates the LSP in steady state, while the alternate egress node (the backup egress) does so when the primary fails. A bypass LSP is established from the penultimate-hop node to the backup egress. The penultimate-hop node, serving as a PLR (point of local repair), redirects traffic to the backup egress node of the LSP using this bypass LSP in the event of primary egress node failure.

The backup egress node forwards the traffic to its ultimate destination using methods that are beyond the scope this document. For example, backup egress node could use the service specific mechanism specified in [pwe3-endpoint-fast-protection] and [l3vpn-egress PE-fast-protection] and mirror the inner labels (e.g. layer-2/3 VPN service labels) from the primary on the backup. The backup would then repair the traffic to its destination based on the mirrored labels. This document focuses on the methods for setting up the bypass LSP to the backup egress so that service specific mechanism could build top on this.

            
                [R1]                       [R8] 
                    \                     /      
               [R2]---[R3]----[R4]-----[R5]---[R6]
                         \             /  \\
                          [R9]-----[R10]   [R7]

                Protected LSP to-R6.x:   [R1->R3->R4->R5->R6.x]
                Protected LSP to-R6.y:   [R1->R3->R4->R5->R6.y]
                Protected LSP to-sec-R6.x:   [R1->R3->R9->R10->R5->R6.x]    
                Protected LSP to-R8.z:   [R2->R3->R4->R5->R8.z]
                x, y, z: Tunnel destination addresses. 
                R6 has x,y destination addresses.
                Egress-Bypass LSP Tunnel by-R7.x: [R5->R7.x]
                Egress-Bypass LSP Tunnel by-R7.y: [R5->R7.y]
                Egress-Bypass LSP Tunnel by-R7.z: [R5->R7.z]

Figure 1

In Figure 1, four LSPs require egress protection. R6 and R8 are the primary egresses. R7 is backup egress for both R6 and R8. R5 is the penultimate hop node. R5 establishes a bypass LSP to R7 to provide fast protection in case R6 or R8 fail. Table 1 shows the bypass LSPs for each of the protected LSPs at R5.

Protected LSP Egress Bypass LSP
to-R6.x by-R7.x
to-R6.y by-R7.y
to-sec-R6.x by-R7.x
to-R8.z by-R7.z

This draft describes two methods for setting up the bypass LSP to the backup egress node, the proxy node method and the alias method.

In the proxy method, an LSP endpoint address is represented as a virtual node in the TE domain, attached to the primary egress node and the backup egress node via bidirectional point-to-point TE links.

              
                [R1]                       [R8] 
                    \                     /      
               [R2]---[R3]----[R4]-----[R5]---[R6]---[x]
                         \             /  \         /
                          [R9]-----[R10]   [R7]---+ 

              x: Tunnel destination addresses in the proxy method.                                                   

Figure 2

With the proxy method, when providing egress protection to the LSPs with destination address x, terminating on primary R6, with backup egress R7, from Figure 1, the topology is modeled as shown in Figure 2.

With this representation, penultimate-hop node R5 could use RFC 4090 RSVP fast-reroute PLR procedures to set up a bypass LSP to the backup egress node R7, by avoiding the primary egress node R6.

In alias method, an LSP endpoint address is associated with a primary egress and a explicit backup egress. The penultimate-hop node of the protected LSP may learn the backup for the LSP from backup egress IGP advertisement or by a local configuration. With this method, the penultimate-hop node can set up a bypass LSP to the backup egress node, by avoiding the primary egress node.

               [R1]                       [R8] 
                    \                     /      
               [R2]---[R3]----[R4]-----[R5]---[R6]x
                         \             /  \       
                          [R9]-----[R10]   [R7](x)  
              x: Tunnel destination addresses. 
              R6 x: R6 primary egress for x. 
              R7(x): R7 Backup egress for x.

Figure 3

In Figure 3, let say x is tunnel destination address and R6 advertise x as secondary loopback address. With this alias representation R5 see the x as x{R6,R7} where R6 is primary and R7 is backup for x. This primary to backup mapping is either learn through R7's IGP backup availability advertisement or by a local configuration in R5.

2. Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

3. Terminology

PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP

PHN: Penultimate Hop Node for an LSP.

Primary egress node: Node terminates a LSP in steady state.

Primary: Primary egress node.

Egress Protected LSP: A Protected LSP that also required protection from primary egress node failure

Backup egress node: Node could rerouted/repaired data carried in a protected LSP

Backup node: Backup egress node.

Protector: Backup egress node.

Protector and Backup node are used interchangeably but convey the same meaning.

4. Proxy method

In this method, an LSP endpoint address is represented as a virtual TE node connected to a primary egress node and a backup egress node with bidirectional TE links, as shown in Figure 2. With this model, node protection establishment and bypass LSP path computation on the penultimate hop of an LSP can follow the procedure described in RFC4090.

4.1. Tunnel destination Advertisement in IGP

Advertising the tunnel destination as a stub proxy TE node requires two steps: 1) a node representation (proxy-node) and 2)links to and from primary egress and backup egress.

The primary advertises a proxy node with two links, to the primary egress and the backup egress, respectively. The router ID of the proxy node is LSP end point address. The system-ID of the proxy is derived from the LSP end point address with BCD encoding. The resulting system-ID and router-ID MUST be unique within the IGP routing domain.

Both stub links are advertised with maximum routable metric and TE metric, and zero bandwidth, as shown in Figure 4. This avoids the proxy node serving as a transit node for any path. The router-ID or system-ID of the backup egress can be dynamically learned from the IGP link state database or can be configured on the primary egress.