wdiff draft-chen-mpls-p2mp-egress-protection-10.txt draft-chen-mpls-p2mp-egress-protection-11.txt

Internet Engineering Task Force H. Chen
Internet-Draft Huawei Technologies
Intended status: Standards Track N. So
Expires: June 1, August 14, 2014 Tata Communications
A. Liu
Ericsson
F. Xu
Verizon
M. Toy
Comcast
L. Huang
China Mobile
L. Liu
UC Davis
November 28, 2013
February 10, 2014

Extensions to RSVP-TE for LSP Egress Local Protection
draft-chen-mpls-p2mp-egress-protection-10.txt
draft-chen-mpls-p2mp-egress-protection-11.txt

Abstract

This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting egress nodes of
a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi-
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network.

Status of this Memo

This Internet-Draft is submitted to IETF 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."

This Internet-Draft will expire on June 1, August 14, 2014.

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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. An Example of Egress Local Protection . . . . . . . . . . 3
1.2. Egress Local Protection with FRR . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
2.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv6
4.1. EGRESS_BACKUP Object . . . . . . . . . . . . . . . . . . . 4
2.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object
4.2. Flags in FAST_REROUTE . . . . . . 5
2.3. . . . . . . . . . . . . 6
4.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6
3.
5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6
3.1.
5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 7
3.2. 6
5.2. Intermediate Node and PLR Behavior . . . . . . . . . . . . 7
3.2.1.
5.2.1. Signaling for One-to-One Protection . . . . . . . . . 8
3.2.2.
5.2.2. Signaling for Facility Protection . . . . . . . . . . 8
3.2.3.
5.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9
3.2.4.
5.2.4. PLR Procedures during Local Repair . . . . . . . . . . 9
4. 10
6. Considering Application Traffic . . . . . . . . . . . . . . . 10
4.1.
6.1. A Typical Application . . . . . . . . . . . . . . . . . . 10
4.2.
6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11
4.3.
6.3. Egress Procedures for Applications . . . . . . . . . . . . 11
5.
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
9. 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1.
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2.
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

1. Introduction

RFC 4090 describes two methods for protecting the transit nodes of a
P2P LSP: one-to-one protection and facility bypass protection. RFC 4875 specifies how
to use them to protect the transit nodes of a P2MP LSP. However, there is no
they do not mention of locally protecting any local protection for an egress of a protected P2P or P2MP LSP in these RFCs. an LSP.

To protect the egresses of an LSP (P2P or P2MP), an existing approach
sets up a backup LSP from a backup ingress (or the ingress of the
LSP) to the backup egresses, where each egress is paired with a
backup egress and protected by the backup egress.

The main disadvantage of this

This approach is that may use more network resources
such as double bandwidths may be used. and provide slow fault recovery.
This document specifies extensions to RSVP-TE for locally protecting local protection of
an egress of a P2MP or P2P an LSP, which overcome this disadvantage. overcomes these disadvantages.

1.1. An Example of Egress Local Protection

Figure 1 illustrates shows an example of using backup LSPs to locally protect egress nodes
egresses of a primary P2MP LSP, which is LSP from ingress
node R1 to two egress nodes: egresses: L1
and L2. The primary LSP is represented by star(*) lines and backup
LSPs by hyphen(-) lines.

La and Lb are the designated backup egress nodes egresses for egress nodes egresses L1 and L2 of the P2MP LSP
respectively. To distinguish between an egress (e.g., L1 in the figure) and L1) from a backup
egress (e.g., La in the
figure), La), an egress is called a primary egress if necessary. needed.

The backup LSP for protecting primary egress L1 is from its upstream node R3 to
backup egress La. The backup LSP one for protecting primary
egress L2 is from its upstream node R5 to backup egress Lb.

[R2]*****[R3]*****[L1]
* \ :.....: $ **** Primary LSP
* \ $ ---- Backup LSP
* \ [CE1] .... BFD Session
* \ $ $ Link
* \ $ $
* [La] $
*
[R1]******[R4]*******[R5]*****[L2]
$ \ :.....: $
$ \ $
[S] \ [CE2]
\ $
\ $
[Lb]

Figure 1: Backup LSP for Locally Protecting Egress

During normal operations, the traffic carried by the P2MP LSP is sent
through R3 to L1, which delivers the traffic to its destination CE1.
When R3 detects the failure of L1, R3 switches the traffic to the
backup LSP to backup egress La, which delivers the traffic to CE1.
The time for switching the traffic is within tens of milliseconds.

The failure of a primary egress (e.g., L1 in the figure) MAY be
detected by its upstream node (e.g., R3 in the figure) through a BFD
session
between the upstream node and the egress in MPLS networks. Exactly
how the failure is detected is out of scope for this document.

Figure 1: Backup LSP for Locally Protecting Egress

1.2. Egress Local Protection with FRR

Using the egress local protection and the FRR, we can locally protect
the egresses, the links and the intermediate nodes of an LSP. The
traffic switchover time is within tens of milliseconds whenever an
egress, any of the links and the intermediate nodes of the LSP fails.

The egress nodes of the LSP can be locally protected via the egress
local protection. All the links and the intermediate nodes of the
LSP can be locally protected through using the FRR.

2. Conventions Used in This Document

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

This document uses terminologies defined in RFC 2205, RFC 3031, RFC
3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875.

4. Protocol Extensions

A new object EGRESS_BACKUP_SUB_LSP EGRESS_BACKUP is defined for signaling egress local protection.
It contains a backup egress for a primary egress.

2.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv6

4.1. EGRESS_BACKUP Object

The class of the EGRESS_BACKUP_SUB_LSP IPv4/IPv6 EGRESS_BACKUP object is 50, which
is the same as that of the S2L_SUB_LSP IPv4/IPv6 object defined in
RFC 4875. TBD-1 to be assigned by
IANA. The C-Type of the EGRESS_BACKUP_SUB_LSP IPv4 EGRESS_BACKUP IPv4/IPv6 object is a
new number 3 or another number TBD-2/
TBD-3 to be assigned by IANA.

EGRESS_BACKUP_SUB_LSP_IPv4

EGRESS_BACKUP Class Num = TBD-1, IPv4/IPv6 C-Type = 3 TBD-2/TBD-3

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~ Egress Backup Sub LSP destination IPv4 IPv4/IPv6 address | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~ Egress Primary Sub LSP destination IPv4 IPv4/IPv6 address | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Subobjects) |
~ (Subobjects) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Egress Backup Sub LSP destination IPv4 address
IPv4 IPv4/IPv6 address:
IPv4/IPv6 address of the backup egress node
o Egress Primary Sub LSP destination IPv4 address
IPv4 IPv4/IPv6 address:
IPv4/IPv6 address of the primary egress node

The Subobjects are optional

The C-Type optional. One of them is P2P LSP ID IPv4/IPv6
subobject, whose body has the EGRESS_BACKUP_SUB_LSP IPv6 object following format and Type is TBD-4/
TBD-5. It may be used to identify a new number 4
or another number assigned by IANA.

EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4 backup LSP.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Backup Sub LSP destination IPv6 address |
~ (16 bytes)
~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Primary Sub P2P LSP destination IPv6 address |
~ (16 Tunnel Egress IPv4/IPv6 Address (4/16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Subobjects) Reserved | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Extended Tunnel ID (4/16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Egress Backup Sub

o P2P LSP destination IPv6 address
IPv6 Tunnel Egress IPv4/IPv6 Address:
IPv4/IPv6 address of the backup egress node
Egress Primary Sub LSP destination IPv6 address
IPv6 address of the primary egress node
Subobjects are optional

2.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object

An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) object tunnel
o Tunnel ID:
A 16-bit identifier that is defined
for signaling protection for a primary egress constant over the life of a P2MP LSP in a new
S2L Sub LSP backup protection method. It contains a path from the
upstream node tunnel
o Extended Tunnel ID:
A 4/16-byte identifier being constant over the life of the primary egress to a backup egress. Its tunnel

Another one is Label subobject, whose body has the format below and
Type is identical TBD-6 to an ERO's.

The class of an EB-SERO is the same as that of a SERO defined in RFC
4873. The EB-SERO uses a new C-Type 3, or another number be assigned by IANA. The formats

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. Flags in FAST_REROUTE

A bit of sub-objects the flags in an EB-SERO are identical the FAST_REROUTE object may be used to
those indicate
whether S2L Sub LSP is desired for protecting an egress of sub-objects in a P2MP LSP
or One-to-One Backup is preferred for protecting an ERO defined in RFC 3209.

2.3. egress of a P2P
LSP when the "Facility Backup Desired" flag is set. This bit is
called "S2L Sub LSP Backup Desired" or "One-to-One Backup Preferred".

4.3. Path Message

A Path message is enhanced to carry the information about a backup
egress for a primary egress of an LSP through including an egress
backup sub LSP descriptor list. The format of the enhanced Path message is
illustrated below.

<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> ]<SESSION> <RSVP_HOP> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> [ <PROTECTION> ] [ <LABEL_SET> ... ] ...]
[ <SESSION_ATTRIBUTE> ] [ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ]
<sender descriptor> [<S2L sub-LSP descriptor list>]
[<egress backup sub LSP descriptor list>]

The egress backup sub LSP descriptor list in the message is defined below.
It is a sequence of EGRESS_BACKUP_SUB_LSP EGRESS_BACKUP objects, each of which describes a
pair of a primary egress and a backup egress.

<egress backup sub LSP descriptor list> ::=
<egress backup sub LSP descriptor>
[ <egress backup sub LSP descriptor list> ]

<egress backup sub LSP descriptor> ::=
<EGRESS_BACKUP_SUB_LSP>
[ <EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE> ]

3. <EGRESS_BACKUP>

5. Egress Protection Behaviors
3.1.

5.1. Ingress Behavior

To protect a primary egress of an LSP, a backup egress must be
configured on the ingress of the LSP.

The ingress initiates a Path message for the LSP with an egress
backup sub LSP descriptor list. For each primary egress of the LSP
to be protected, the ingress MUST add an EGRESS_BACKUP_SUB_LSP object
into the list. The object contains set the primary egress
"label recording desired" flag and the backup
egress for protecting "node protection desired" flag
in the primary egress.

To SESSION_ATTRIBUTE object.

If one-to-one backup or facility backup method is desired to protect
a primary egress of an LSP via one-to-one backup or
facility backup method, LSP, the ingress SHOULD include a FAST_REROUTE
object and set the One-to-One "One-to-One Backup Desired Desired" or Facility "Facility Backup
Desired
Desired" flag.

To protect a primary

If S2L Sub LSP backup method is desired to protect a primary egress
of a P2MP LSP via S2L LSP, the ingress SHOULD include a FAST_REROUTE object and
set the "S2L Sub LSP backup
method, Backup Desired" flag.

Note that if "Facility Backup Desired" flag is set for protecting the
intermediate nodes of a primary P2P LSP, but we want to use "One-to-
One Backup" for protecting the egress of the LSP, then the ingress
SHOULD add an EB-SERO object following set "One-to-One Backup Preferred" flag.

Optionally, a backup egress may be configured on the
EGRESS_BACKUP_SUB_LSP object into ingress of an
LSP to protect a primary egress of the list. LSP.

The EB-SERO object
contains ingress sends a path from Path message for the upstream node of LSP with the objects above
and an optional egress backup descriptor list. For each primary
egress of the LSP to be protected, the
backup egress. The ingress computes adds an EGRESS_BACKUP
object into the path list if the P2MP LSP backup egress is in
one area; otherwise, given. The object
contains the path may be computed by primary egress and the Path Computation
Element (PCE).

3.2. backup egress for protecting the
primary egress.

5.2. Intermediate Node and PLR Behavior

If an intermediate node of an LSP receives the Path message with an
egress backup sub LSP descriptor list and it is not an upstream node of any
primary egress of the LSP, it forwards the list in the message unchanged.

If the intermediate node is the upstream node of a primary egress to
be protected, it gets determines the backup egress egress, obtains a path for the
backup LSP and sets up the backup LSP along the path.

The PLR (upstream node of the primary egress) tries to get the backup
egress from EGRESS_BACKUP in the egress backup descriptor list if the
Path message contains the list. If the PLR can not get it, the PLR
tries to find the backup egress, which is not the primary egress but
has the same IP address as the destination IP address of the LSP.

Note that the primary egress and the backup egress SHOULD have a same
local address configured, and the cost to the local address on the
backup egress SHOULD be much bigger than the cost to the local
address on the primary egress. Thus another name such as virtual
node based egress protection may be used for egress local protection.

After obtaining the backup egress, the PLR tries to compute a path
from itself to the backup egress.

The PLR then sets up the EGRESS_BACKUP_SUB_LSP object in backup LSP along the list. path obtained. It acts as a PLR to
provide
provides one-to-one or facility backup protection for the primary
egress. It provides one-to-one backup protection egress if the One-to-One
"One-to-One Backup Desired Desired" or "One-to-One Backup Preferred" flag is
set in the message; otherwise, it provides facility backup protection
if the Facility "Facility Backup Desired flag flag" is set.

The PLR (upstream node of the primary egress) sets the protection flags in the RRO Sub-object for the
primary egress in the Resv message according to the status of the
primary egress and the backup LSP protecting the primary egress. For
example, it will set the "local protection available" and the "node
protection" flag to one indicating that the primary egress is protected when
the backup LSP
to the backup egress is set up and ready for protecting the primary egress.

3.2.1.

5.2.1. Signaling for One-to-One Protection

The behavior of the upstream node of a primary egress of an LSP as a
PLR is the same as that of a PLR for one-to-one backup method
described in RFC 4090 except for that the upstream node creates a
backup LSP from itself to a backup egress.

In the case that

If the LSP is a P2MP LSP and a primary egress of the LSP is a transit
node (i.e., bud node), the upstream node of the primary egress as a
PLR also creates a backup LSP from itself to each of the next hops of
the primary egress.

When the PLR detects a the failure in of the primary egress, it MUST rapidly
switch the packets from the primary LSP to the backup LSP to the
backup egress. For a the failure in of the bud node of an a P2MP LSP, the
PLR MUST also rapidly switch the packets to the backup LSPs to the bud node's
next hops, where the packets are merged into the primary LSP.

3.2.2.

5.2.2. Signaling for Facility Protection

Except for backup LSP and downstream label, the behavior of the
upstream node of the primary egress of a primary LSP as a PLR follows
the PLR behavior for facility backup method described in RFC 4090.

For a number of primary P2P LSPs going through the same PLR to the
same primary egress, the primary egress of these LSPs may be
protected by one backup LSP from the PLR to the backup egress
designated for protecting the primary egress.

The PLR selects or creates a backup LSP from itself to the backup
egress. If there exists is a backup LSP that satisfies the constraints
given in the Path message, then this one is selected; otherwise, a
new backup LSP to the backup egress will be created.

For a primary LSP carrying IP packets,

After getting the backup LSP, the PLR does not need any
downstream label as an inner label for associates the backup LSP when binding the with
a primary LSP with for protecting its primary egress. The PLR records
that the backup LSP. When LSP is used to protect the PLR detects a primary LSP against its
primary egress failure and includes an EGRESS_BACKUP object in the
Path message to the primary egress, it redirects egress. The object contains the IP packets from backup
egress and the primary backup LSP
into ID. It indicates that the primary egress
SHOULD send the backup egress the primary LSP to label as UA label.

After receiving the backup egress, where Path message with the IP packets are
forwarded according to IP destinations in EGRESS_BACKUP, the primary
egress includes the information about the packets.

For a primary LSP carrying packets label in the
Resv message with application or service
labels, an EGRESS_BACKUP object as UA label. When the PLR may not need any downstream label as an inner label
receives the Resv message with the information about the UA label, it
includes the information in the Path message for the backup LSP either when binding to
the backup egress. Thus the primary LSP with label as UA label is sent to
the backup LSP. egress from the primary egress.

When the PLR detects a the failure in of the primary egress, it redirects
the packets from the primary LSP into the backup LSP to backup egress
through switching
using the top primary LSP label with from the backup LSP primary egress as an inner
label. The backup egress delivers the packets to the same
destinations as the primary egress (see details in section "Considering Application
Traffic" below).

3.2.3. using the backup LSP label as
context label and the inner label as UA label.

5.2.3. Signaling for S2L Sub LSP Protection

The S2L Sub LSP Protection is used to protect a primary egress of a
P2MP LSP. Its major advantage is that the application traffic
carried by the P2MP LSP may be is easily protected against the egress failure.

The PLR determines to protect a primary egress of a P2MP LSP via S2L
sub LSP protection when it receives a Path message with an EB-SERO
object following the EGRESS_BACKUP_SUB_LSP containing the primary
egress and a backup egress. flag "S2L Sub
LSP Backup Desired" set.

The PLR sets up the backup S2L sub LSP to the backup egress, creates
and maintains its state in the same way as of setting up a source to
leaf (S2L) sub LSP defined in RFC 4875 from the signaling's point of
view. It computes a path for the backup LSP from itself to the
backup egress, constructs and sends a PATH Path message along the path given in
the EB-SERO for the backup LSP, path,
receives and processes a RESV Resv message
that responses responding to the PATH Path message.

After receiving the RESV Resv message for the backup LSP, the PLR creates
a forwarding entry with an inactive state or flag called inactive
forwarding entry. This inactive forwarding entry is not used to
forward any data traffic during normal operations.

When the PLR detects a the failure in of the primary egress failure, egress, it changes
the forwarding entry for the backup LSP to active. Thus, the PLR
forwards the traffic to the backup egress through the backup LSP,
which sends the traffic to its destination.

3.2.4.

5.2.4. PLR Procedures during Local Repair

When the upstream node of a primary egress of an LSP as a PLR detects
a
the failure in of the primary egress, it follows the procedures defined
in section 6.5 of RFC 4090.

The PLR (i.e., the upstream node of the primary egress) It SHOULD notify the ingress about the
failure of the primary egress in the same way as a PLR notifies the
ingress about the failure of an intermediate node.

In the local revertive mode, the PLR re-signals each of the primary
LSPs that used to be were routed over the restored resource once it detects that
the resource is restored. Every primary LSP successfully re-signaled
along the restored resource is switched back.

Moreover, the PLR lets the upstream part of the primary LSP stay
after the primary egress fails. The downstream part of the primary
LSP from the PLR to the primary egress SHOULD be removed.

6. Considering Application Traffic

This section focuses on the application traffic carried by P2P LSPs.
When a primary egress of a P2MP LSP fails, the application traffic
carried by the P2MP LSP may be delivered to the same destination by
the backup egress since the inner label if any for the traffic is a
upstream assigned label for every egress of the P2MP LSP.

4.1.

6.1. A Typical Application

L3VPN is a typical application that an LSP carries. application. An existing solution (refer to
Figure 2) for protecting L3VPN traffic against egress failure
includes: 1) A multi-hop BFD session between ingress R1 and egress L1
of primary LSP; 2) A backup LSP from ingress R1 to backup egress La;
3) La sends R1 VPN backup label and related information via BGP; 4)
R1 has a VRF with two sets of routes: one uses primary LSP and L1 as
next hop; the other uses backup LSP and La as next hop.

CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP
one VPN * : $ ---- Backup LSP
* .................: $ .... BFD Session
[R1] ..: [CE2] $ Link
$ \ $ $
$ \ $
[CE1] [R4]-----[R5]-----[La](BGP sends R1 VPN backup label)

Figure 2: Protect Egress for L3VPN Traffic

In normal operations, R1 sends the traffic from CE1 through primary
LSP with VPN label received from L1 as inner label to L1, which
delivers the traffic to CE2 using VPN label.

When R1 detects a the failure in of L1, R1 sends the traffic from CE1 via
backup LSP with VPN bakup backup label received from La as inner label to
La, which delivers the traffic to CE2 using VPN backup label.

A new solution (refer to Figure 3) with egress local protection for
protecting L3VPN traffic includes: 1) A BFD session between R3 and
egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress
La; 3) L1 sends La VPN label as UA label and related information via
BGP or another protocol; information; 4)
L1 and La is virtualized as one from R1's
point one. This can be achieved by configuring
a same local address on L1 and La, using the address as a destination
of view. the LSP and BGP next hop for VPN traffic.

CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP
one VPN * \ :.....: $ ---- Backup LSP
* \ $ .... BFD Session
[R1] \ [CE2] $ Link
$ \ $ $
$ \ $
[CE1] [La](VPN label from L1 as UA label)

Figure 3: Locally Protect Egress for L3VPN Traffic

When R3 detects a failure in L1, L1's failure, R3 sends the traffic from primary LSP
via backup LSP to La, which delivers the traffic to CE2 using VPN
label as UA label under the backup LSP label as a context label.

4.2.

6.2. PLR Procedure for Applications

When the PLR creates gets a backup LSP from itself to a backup egress for
protecting a primary egress, egress of a primary LSP, it includes an EGRESS_BACKUP_SUB_LSP
EGRESS_BACKUP object in the Path message for the primary LSP. The
object contains the
primary egress and ID information of the backup egress LSP and indicates
that the backup primary egress SHOULD consider send the backup LSP label as a context label and egress the inner label as application
traffic label (e.g., VPN label) as UA label when needed.

4.3.

6.3. Egress Procedures for Applications

When a primary egress of an LSP sends the ingress of the LSP a label
for an application such as a VPN, it SHOULD sends send the backup egress
for protecting the primary egress the label as a upstream assigned UA label via BGP or
another protocol. Exactly how the label is sent is out of scope for
this document.

When the backup egress receives a upstream assigned UA label from the primary egress,
it adds a forwarding entry with the label into the LFIB for the
primary egress. Using this entry, the backup egress
delivers the traffic with this label as inner label from the backup
LSP to the same destination as the primary egress. When the backup egress receives a packet from the
backup LSP, it uses the top label as a context label to find the LFIB
for the primary egress and the inner label to deliver the packet to
the same destination as the primary egress according to the LFIB.

7. Security Considerations

In principle this document does not introduce new security issues.
The security considerations pertaining to RFC 4090, RFC 4875 and
other RSVP protocols remain relevant.

8. IANA Considerations

TBD

IANA considerations for new objects will be specified after the
objects used are decided upon.

9. Contributors

Boris Zhang
Telus Communications
200 Consilium Pl Floor 15
Toronto, ON M1H 3J3
Canada
Email: Boris.Zhang@telus.com

Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com

Nan Meng
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: mengnan@huawei.com

Vic Liu
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053
China

8.
Email: liuzhiheng@chinamobile.com

10. Acknowledgement

The authors would like to thank Richard Li, Tarek Saad, Lizhong Jin,
Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, Rob Rennison,
Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam and Quintin
Zhao for their valuable comments and suggestions on this draft.

11. References

9.1.

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.

[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.

[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.

[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, August 2008.

[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
Local Addresses in OSPF Traffic Engineering (TE)
Extensions", RFC 5786, March 2010.

[P2MP FRR]
Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux,
"P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels",
draft-leroux-mpls-p2mp-te-bypass , March 1997.

9.2.

11.2. Informative References

[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.

Authors' Addresses

Huaimo Chen
Huawei Technologies
Boston, MA
USA

Email: huaimo.chen@huawei.com

Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA

Email: ning.so@tatacommunications.com

Autumn Liu
Ericsson
CA
USA

Email: autumn.liu@ericsson.com
Fengman Xu
Verizon
2400 N. Glenville Dr
Richardson, TX 75082
USA

Email: fengman.xu@verizon.com

Mehmet Toy
Comcast
1800 Bishops Gate Blvd.
Mount Laurel, NJ 08054
USA

Email: mehmet_toy@cable.comcast.com

Lu Huang
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing, 100053
China

Email: huanglu@chinamobile.com

Lei Liu
UC Davis
USA

Email: liulei.kddi@gmail.com