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 DavisNovember 28, 2013February 10, 2014 Extensions to RSVP-TE for LSP Egress Local Protectiondraft-chen-mpls-p2mp-egress-protection-10.txtdraft-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 onJune 1,August 14, 2014. Copyright Notice Copyright (c)20132014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 42.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv64.1. EGRESS_BACKUP Object . . . . . . . . . . . . . . . . . . . 42.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object4.2. Flags in FAST_REROUTE . . . . . .5 2.3.. . . . . . . . . . . . 6 4.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 63.5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 63.1.5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . .7 3.2.6 5.2. Intermediate Node and PLR Behavior . . . . . . . . . . . . 73.2.1.5.2.1. Signaling for One-to-One Protection . . . . . . . . . 83.2.2.5.2.2. Signaling for Facility Protection . . . . . . . . . . 83.2.3.5.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 93.2.4.5.2.4. PLR Procedures during Local Repair . . . . . . . . . .9 4.10 6. Considering Application Traffic . . . . . . . . . . . . . . . 104.1.6.1. A Typical Application . . . . . . . . . . . . . . . . . . 104.2.6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 114.3.6.3. Egress Procedures for Applications . . . . . . . . . . . . 115.7. Security Considerations . . . . . . . . . . . . . . . . . . . 126.8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 127.9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 128.10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .12 9.13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 139.1.11.1. Normative References . . . . . . . . . . . . . . . . . . . 139.2.11.2. Informative References . . . . . . . . . . . . . . . . . .1314 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction RFC 4090 describes two methods for protecting the transit nodes of a P2P LSP: one-to-oneprotectionand facilitybypassprotection. RFC 4875 specifies how to use them to protect the transit nodes of a P2MP LSP. However,there is nothey do not mentionof locally protectingany local protection for an egress ofa 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 thisThis approachis thatmay use morenetworkresourcessuch as double bandwidths may be used.and provide slow fault recovery. This document specifies extensions to RSVP-TE forlocally protectinglocal protection of an egress ofa P2MP or P2Pan LSP, whichovercome this disadvantage.overcomes these disadvantages. 1.1. An Example of Egress Local Protection Figure 1illustratesshows an example of using backup LSPs to locally protectegress nodesegresses of a primary P2MPLSP, which isLSP from ingressnodeR1 to twoegress 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 backupegress nodesegresses foregress nodesegresses L1 and L2of the P2MP LSPrespectively. To distinguishbetweenan egress (e.g.,L1 in the figure) andL1) from a backup egress (e.g.,La in the figure),La), an egress is called a primary egress ifnecessary.needed. The backup LSP for protectingprimary egressL1 is from its upstream node R3 to backup egress La. Thebackup LSPone for protectingprimary egressL2 is fromits upstream nodeR5 tobackup egressLb. [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 BFDsessionbetween the upstream node and the egress in MPLS networks. Exactly how the failure is detected is out of scope for this document.[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 Egress1.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 objectEGRESS_BACKUP_SUB_LSPEGRESS_BACKUP is defined forsignalingegress local protection. It contains a backup egress for a primary egress.2.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv64.1. EGRESS_BACKUP Object The class of theEGRESS_BACKUP_SUB_LSP IPv4/IPv6EGRESS_BACKUP object is50, 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 theEGRESS_BACKUP_SUB_LSP IPv4EGRESS_BACKUP IPv4/IPv6 object isa new number 3 or another numberTBD-2/ TBD-3 to be assigned by IANA.EGRESS_BACKUP_SUB_LSP_IPv4EGRESS_BACKUP Class Num = TBD-1, IPv4/IPv6 C-Type =3TBD-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 BackupSub LSPdestinationIPv4IPv4/IPv6 address|~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|~ Egress PrimarySub LSPdestinationIPv4IPv4/IPv6 address|~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| (Subobjects) |~ (Subobjects) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Egress BackupSub LSPdestinationIPv4 address IPv4IPv4/IPv6 address: IPv4/IPv6 address of the backup egress node o Egress PrimarySub LSPdestinationIPv4 address IPv4IPv4/IPv6 address: IPv4/IPv6 address of the primary egress node The Subobjects areoptional The C-Typeoptional. One of them is P2P LSP ID IPv4/IPv6 subobject, whose body has theEGRESS_BACKUP_SUB_LSP IPv6 objectfollowing format and Type is TBD-4/ TBD-5. It may be used to identify anew number 4 or another number assigned by IANA. EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4backup 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 SubP2P LSPdestination IPv6 address | ~ (16Tunnel Egress IPv4/IPv6 Address (4/16 bytes) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(Subobjects)Reserved | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Extended Tunnel ID (4/16 bytes) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Egress Backup Subo P2P LSPdestination IPv6 address IPv6Tunnel Egress IPv4/IPv6 Address: IPv4/IPv6 address of thebackupegressnode Egress Primary Sub LSP destination IPv6 address IPv6 addressof theprimary egress node Subobjects are optional 2.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) objecttunnel o Tunnel ID: A 16-bit identifier that isdefined for signaling protection for a primary egressconstant over the life ofa P2MP LSP in a new S2L Sub LSP backup protection method. It contains a path fromtheupstream nodetunnel o Extended Tunnel ID: A 4/16-byte identifier being constant over the life of theprimary egress to a backup egress. Itstunnel Another one is Label subobject, whose body has the format below and Type isidenticalTBD-6 toan 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 numberbe assigned by IANA.The formats0 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 ofsub-objectsthe flags inan EB-SERO are identicalthe FAST_REROUTE object may be used tothoseindicate whether S2L Sub LSP is desired for protecting an egress ofsub-objects ina P2MP LSP or One-to-One Backup is preferred for protecting anERO 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 backupsub LSPdescriptor 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 backupsub LSPdescriptor list>] The egress backupsub LSPdescriptor list in the message is defined below. It is a sequence ofEGRESS_BACKUP_SUB_LSPEGRESS_BACKUP objects, each of which describes a pair of a primary egress and a backup egress. <egress backupsub LSPdescriptor list> ::= <egress backupsub LSPdescriptor> [ <egress backupsub LSPdescriptor list> ] <egress backupsub LSPdescriptor> ::=<EGRESS_BACKUP_SUB_LSP> [ <EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE> ] 3.<EGRESS_BACKUP> 5. Egress Protection Behaviors3.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 MUSTadd an EGRESS_BACKUP_SUB_LSP object into the list. The object containsset theprimary egress"label recording desired" flag and thebackup egress for protecting"node protection desired" flag in theprimary egress. ToSESSION_ATTRIBUTE object. If one-to-one backup or facility backup method is desired to protect a primary egress of anLSP via one-to-one backup or facility backup method,LSP, the ingress SHOULD include a FAST_REROUTE object and set theOne-to-One"One-to-One BackupDesiredDesired" orFacility"Facility BackupDesiredDesired" flag.To protect a primaryIf S2L Sub LSP backup method is desired to protect a primary egress of a P2MPLSP via S2LLSP, the ingress SHOULD include a FAST_REROUTE object and set the "S2L Sub LSPbackup 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 SHOULDadd an EB-SERO object followingset "One-to-One Backup Preferred" flag. Optionally, a backup egress may be configured on theEGRESS_BACKUP_SUB_LSP object intoingress of an LSP to protect a primary egress of thelist.LSP. TheEB-SERO object containsingress sends apath fromPath message for theupstream node ofLSP with the objects above and an optional egress backup descriptor list. For each primary egress of the LSP to be protected, thebackup egress. Theingresscomputesadds an EGRESS_BACKUP object into thepathlist if theP2MP LSPbackup egress isin one area; otherwise,given. The object contains thepath may be computed byprimary egress and thePath 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 backupsub LSPdescriptor list and it is not an upstream node of any primary egress of the LSP, it forwards the listin the messageunchanged. If the intermediate node is the upstream node of a primary egress to be protected, itgetsdetermines the backupegressegress, 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 theEGRESS_BACKUP_SUB_LSP object inbackup LSP along thelist.path obtained. Itacts as a PLR to provideprovides one-to-oneor facilitybackup protection for the primaryegress. It provides one-to-one backup protectionegress if theOne-to-One"One-to-One BackupDesiredDesired" or "One-to-One Backup Preferred" flag is set in the message; otherwise, it provides facility backup protection if theFacility"Facility Backup Desiredflagflag" 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" flagto oneindicating that the primary egress is protected when the backup LSPto the backup egressissetup 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 thatIf 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 detectsathe failureinof the primary egress, it MUSTrapidlyswitch the packets from the primary LSP to the backup LSP to the backup egress. Forathe failureinof the bud node ofana P2MP LSP, the PLR MUST alsorapidlyswitch 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 thereexistsis 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 PLRdoes not need any downstream label as an inner label forassociates the backup LSPwhen binding thewith a primary LSPwithfor protecting its primary egress. The PLR records that the backupLSP. WhenLSP is used to protect thePLR detects aprimary LSP against its primary egress failure and includes an EGRESS_BACKUP object in the Path message to the primaryegress, it redirectsegress. The object contains theIP packets frombackup egress and theprimarybackup LSPintoID. It indicates that the primary egress SHOULD send the backup egress the primary LSPtolabel as UA label. After receiving thebackup egress, wherePath message with theIP packets are forwarded according to IP destinations inEGRESS_BACKUP, the primary egress includes the information about thepackets. For aprimary LSPcarrying packetslabel in the Resv message withapplication or service labels,an EGRESS_BACKUP object as UA label. When the PLRmay not need any downstream label as an inner labelreceives the Resv message with the information about the UA label, it includes the information in the Path message for the backup LSPeither when bindingto the backup egress. Thus the primary LSPwithlabel as UA label is sent to the backupLSP.egress from the primary egress. When the PLR detectsathe failureinof the primary egress, it redirects the packets from the primary LSP into the backup LSP to backup egressthrough switchingusing thetopprimary LSP labelwithfrom thebackup LSPprimary 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 theP2MPLSPmay beis 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 withan 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 aPATHPath message along thepath given in the EB-SERO for the backup LSP,path, receives and processes aRESVResv messagethat responsesresponding to thePATHPath message. After receiving theRESVResv 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 detectsathe failureinof the primaryegress 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 detectsathe failureinof 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 thatused to bewere 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.4.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 typicalapplication 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 detectsathe failureinof L1, R1 sends the traffic from CE1 via backup LSP with VPNbakupbackup 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 relatedinformation via BGP or another protocol;information; 4) L1 and La is virtualized asone from R1's pointone. This can be achieved by configuring a same local address on L1 and La, using the address as a destination ofview.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 detectsa 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 PLRcreatesgets a backup LSP from itself to a backup egress for protecting a primaryegress,egress of a primary LSP, it includes anEGRESS_BACKUP_SUB_LSPEGRESS_BACKUP object in the Path message for the primary LSP. The object contains theprimary egress andID information of the backupegressLSP and indicates that thebackupprimary egress SHOULDconsidersend the backupLSP label as a context label andegress theinner label asapplication 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 SHOULDsendssend the backup egress for protecting the primary egress the label as aupstream assignedUA label via BGP or another protocol. Exactly how the label is sent is out of scope for this document. When the backup egress receives aupstream assignedUA 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.5.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.6.8. IANA ConsiderationsTBD 7.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 China8.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.9.11. References9.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