[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-ietf-mpls-rsvp-egress-protection) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 8400

Internet Engineering Task Force                                  H. Chen
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                  A. Liu
Expires: April 18, 2018                                            Ciena
                                                                 T. Saad
                                                           Cisco Systems
                                                                   F. Xu
                                                                 Verizon
                                                                L. Huang
                                                            China Mobile
                                                        October 15, 2017


         Extensions to RSVP-TE for LSP Egress Local Protection
             draft-ietf-teas-rsvp-egress-protection-09.txt

Abstract

   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for locally protecting the egress
   node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP)
   Traffic Engineered (TE) Label Switched Path (LSP).

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 April 18, 2018.

Copyright Notice

   Copyright (c) 2017 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



Chen, et al.             Expires April 18, 2018                 [Page 1]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   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.  Egress Local Protection  . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Protocol Extensions  . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Extensions to SERO . . . . . . . . . . . . . . . . . . . .  4
       4.1.1.  Primary Egress Subobject . . . . . . . . . . . . . . .  6
       4.1.2.  P2P LSP ID Subobject . . . . . . . . . . . . . . . . .  6
   5.  Egress Protection Behaviors  . . . . . . . . . . . . . . . . .  7
     5.1.  Ingress Behavior . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Primary Egress Behavior  . . . . . . . . . . . . . . . . .  8
     5.3.  Backup Egress Behavior . . . . . . . . . . . . . . . . . .  8
     5.4.  Transit Node and PLR Behavior  . . . . . . . . . . . . . .  9
       5.4.1.  Signaling for One-to-One Protection  . . . . . . . . . 10
       5.4.2.  Signaling for Facility Protection  . . . . . . . . . . 10
       5.4.3.  Signaling for S2L Sub LSP Protection . . . . . . . . . 11
       5.4.4.  PLR Procedures during Local Repair . . . . . . . . . . 12
   6.  Considering Application Traffic  . . . . . . . . . . . . . . . 12
     6.1.  A Typical Application  . . . . . . . . . . . . . . . . . . 12
     6.2.  PLR Procedure for Applications . . . . . . . . . . . . . . 13
     6.3.  Egress Procedures for Applications . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Co-authors and Contributors  . . . . . . . . . . . . . . . . . 15
   10. Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 16
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17












Chen, et al.             Expires April 18, 2018                 [Page 2]


Internet-Draft         RSVP LSP Egress Protection           October 2017


1.  Introduction

   RFC 4090 describes two methods for locally protecting the transit
   nodes of a P2P LSP: one-to-one and facility protection.  RFC 4875
   specifies how these methods can be used to protect the transit nodes
   of a P2MP LSP.  These documents do not discuss the procedures for
   locally protecting the egress node(s) of an LSP.

   This document fills that void and specifies extensions to RSVP-TE for
   local protection of the egress node(s) of an LSP.

1.1.  Egress Local Protection

   Figure 1 shows an example of using backup LSPs to locally protect
   egresses of a primary P2MP LSP from ingress R1 to two egresses, L1
   and L2.  La and Lb are the designated backup egresses for primary
   egresses L1 and L2 respectively.  The backup LSP for protecting L1 is
   from its upstream node R3 to backup egress La and the backup LSP for
   protecting L2 is from R5 to Lb.

                        *******  *******                 S Source
                     [R2]-----[R3]-----[L1]            CEx Customer Edge
                    */           &\        \            Rx Non-Egress
                   */             &\        \           Lx Egress
                  */               &\        [CE1]     *** Primary LSP
                 */                 &\      /          &&& Backup LSP
                */                   &\    /
               */                      [La]
              */
             */
            */
           */ ********  ********  *******
     [S]---[R1]------[R4]------[R5]-----[L2]
                                  &\        \
                                   &\        \
                                    &\        [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.




Chen, et al.             Expires April 18, 2018                 [Page 3]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   The exact mechanism by which the failure of the primary egress is
   detected by the upstream node is out of the scope of this document.


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 3209, RFC
   4090, RFC 4873 and RFC 4875.


4.  Protocol Extensions

4.1.  Extensions to SERO

   The Secondary Explicit Route object (SERO) is defined in RFC 4873.
   The format of the SERO is re-used.

   The SERO used for protecting a primary egress node of a primary LSP
   may be added into the Path messages for the LSP and sent from the
   ingress node of the LSP to the upstream node of the egress node.  It
   contains three subobjects.

   The first subobject indicates the branch node that is to originate
   the backup LSP (to a backup egress node).  The branch node is the
   direct upstream node of the primary egress node of the primary LSP if
   it can provide fast local protection for the primary egress node.
   The branch node can be a (upstream) node on the primary LSP, but not
   the direct upstream node if the direct upstream node does not provide
   any fast local protection against the failure of the primary egress
   node.  In this case, the backup LSP from the branch node to the
   backup egress node protects against failures on the segment of the
   primary LSP from the branch node to the primary egress node,
   including the primary egress node.

   The final (third) subobject in the SERO contains the egress node of
   the backup LSP, i.e., the address of the backup egress node.

   The second subobject is an egress protection subobject, which is a
   PROTECTION object with a new C-TYPE (3).  The format of the egress
   protection subobject is defined as follows:




Chen, et al.             Expires April 18, 2018                 [Page 4]


Internet-Draft         RSVP LSP Egress Protection           October 2017


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |    Reserved   |   C-Type (3)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                   |E-Flags|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Optional subobjects                       |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E-Flags are defined for egress local protection.

   x01 (Egress local protection bit):  It is set (1) to indicate an
      egress local protection.

   x02 (S2L sub LSP backup desired bit):  It is set (1) to indicate S2L
      Sub LSP (ref to RFC 4875) is desired for protecting an egress of a
      P2MP LSP.

   The Reserved parts MUST set to zero.

   Four optional subobjects are defined.  They are IPv4 and IPv6 primary
   egress, IPv4 and IPv6 P2P LSP ID subobjects.  They have the following
   format:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |            Length             |Reserved (zero)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Contents/Body of subobject                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where Type is the type of a subobject, Length is the total size of
   the subobject in bytes, including Type, Length and Contents fields.
   The Reserved field MUST be set to zero.

   After the upstream node of the primary egress node as the branch node
   receives the SERO and determines a backup egress node for the primary
   egress, it computes a path from itself to the backup egress node and
   sets up a backup LSP along the path for protecting the primary egress
   node according to the information in the FAST_REROUTE object in the
   Path message.  For example, if facility protection is desired,
   facility protection is provided for the primary egress node.

   The upstream node constructs a new SERO based on the SERO received
   and adds the new SERO into the Path message for the backup LSP.  The



Chen, et al.             Expires April 18, 2018                 [Page 5]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   new SERO also contains three subobjects as the SERO for the primary
   LSP.  The second subobject in the new SERO includes a primary egress,
   which indicates the address of the primary egress node.  The third
   one contains the backup egress.

   The upstream node updates the SERO in the Path message for the
   primary LSP.  The egress protection subobject in the SERO contains a
   subobject called a P2P LSP ID subobject, which contains the
   information for identifying the backup LSP.  The final subobject in
   the SERO indicates the address of the backup egress node.

4.1.1.  Primary Egress Subobject

   There are two primary egress subobjects.  One is IPv4 primary egress
   subobject and the other is IPv6 primary egress subobject.

   The Type of an IPv4 primary egress subobject is 1, and the body of
   the subobject is given below:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    IPv4 address (4 bytes)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o IPv4 address: IPv4 address of the primary egress node

   The Type of an IPv6 primary egress subobject is 2, and the body of
   the subobject is shown below:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    IPv6 address (16 bytes)                    |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o IPv6 address: The IPv6 address of the primary egress node

4.1.2.  P2P LSP ID Subobject

   A P2P LSP ID subobject contains the information for identifying a
   backup point-to-point (P2P) LSP tunnel.

4.1.2.1.  IPv4 P2P LSP ID Subobject

   The Type of an IPv4 P2P LSP ID subobject is 3, and the body of the
   subobject is shown below:



Chen, et al.             Expires April 18, 2018                 [Page 6]


Internet-Draft         RSVP LSP Egress Protection           October 2017


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               P2P LSP Tunnel Egress IPv4 Address              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved (MUST be zero)    |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Extended Tunnel ID                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     o P2P LSP Tunnel Egress IPv4 Address:
         IPv4 address of the egress of the tunnel
     o Tunnel ID:
         A 16-bit identifier being constant over the life of the tunnel
     o Extended Tunnel ID:
         A 4-byte identifier being constant over the life of the tunnel

4.1.2.2.  IPv6 P2P LSP ID Subobject

   The Type of an IPv6 P2P LSP ID subobject is 4, and the body of the
   subobject is illustrated below:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~         P2P LSP Tunnel Egress IPv6 Address (16 bytes)         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved (MUST be zero)    |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                 Extended Tunnel ID (16 bytes)                 ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     o P2P LSP Tunnel Egress IPv6 Address:
         IPv6 address of the egress of the tunnel
     o Tunnel ID:
         A 16-bit identifier being constant over the life of the tunnel
     o Extended Tunnel ID:
         A 16-byte identifier being constant over the life of the tunnel


5.  Egress Protection Behaviors

5.1.  Ingress Behavior

   To protect a primary egress of an LSP, the ingress MUST set the
   "label recording desired" flag and the "node protection desired" flag



Chen, et al.             Expires April 18, 2018                 [Page 7]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   in the SESSION_ATTRIBUTE object.

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

   If S2L Sub LSP backup is desired to protect a primary egress of a
   P2MP LSP, the ingress MUST set the "S2L Sub LSP Backup Desired" flag
   in an SERO object.

   A backup egress MUST be configured on the ingress of an LSP to
   protect a primary egress of the LSP if and only if the backup egress
   is not indicated in another place.

   The ingress MUST send a Path message for the LSP with the objects
   above and the SEROs for protecting egresses of the LSP.  For each
   primary egress of the LSP to be protected, the ingress MUST add an
   SERO object into the Path message if the backup egress or some
   options are given.  If the backup egress is given, then the final
   subobject in the SERO containts it; otherwise the address in the
   final subobject is zero.

5.2.  Primary Egress Behavior

   To protect a primary egress of an LSP, a backup egress MUST be
   configured on the primary egress of the LSP to protect the primary
   egress if and only if the backup egress is not indicated in another
   place.

   If the backup egress is configured on the primary egress of the LSP,
   the primary egress MUST send its upstream node a Resv message for the
   LSP with an SERO for protecting the primary egress.  It sets the
   flags in the SERO in the same way as an ingress.

   If the LSP carries the service traffic with a service label, the
   primary egress sends its corresponding backup egress the information
   about the service label as a UA label and the related forwarding.

5.3.  Backup Egress Behavior

   When a backup egress node receives a Path message for an LSP, it
   determines whether the LSP is used for egress local protection
   through checking the SERO with egress protection subobject in the
   message.  If there is an egress protection subobject in the Path
   message for the LSP and the Egress local protection flag in the
   object is set to one, the LSP is the backup LSP for egress local
   protection.  The primary egress to be protected is in the primary



Chen, et al.             Expires April 18, 2018                 [Page 8]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   egress subobject in the SERO.

   When the backup egress receives the information about a UA label and
   its related forwarding from the primary egress, it uses the backup
   LSP label as a context label and creates a forwarding entry using the
   information about the UA label and the related forwarding.  This
   forwarding entry is in a forwarding table for the primary egress
   node.

   When the primary egress node fails, its upstream node switches the
   traffic from the primary LSP to the backup LSP to the backup egress
   node, which delivers the traffic to its receiver such as CE using the
   backup LSP label as a context label to get the forwarding table for
   the primary egress node and the service label as UA label to find the
   forwarding entry in the table to forward the traffic to the receiver.

5.4.  Transit Node and PLR Behavior

   If a transit node of an LSP receives the Path message with the SEROs
   and it is not an upstream node of any primary egress of the LSP as a
   branch node, it MUST forward them unchanged.

   If the transit node is the upstream node of a primary egress to be
   protected as a branch node, it determines the backup egress, obtains
   a path for the backup LSP and sets up the backup LSP along the path.
   If the upstream node receives the Resv message with an SERO object,
   it MUST sends its upstream node the Resv message without the object.

   The PLR (upstream node of the primary egress as the branch node) MUST
   extract the backup egress from the respective SERO object in either a
   Path or a Resv message.  If no matching SERO object is found, 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 if a backup egress is not configured explicitly for
   protecting a primary egress, 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 primary egress
   and backup egress is considered as a virtual node.  Note that the
   backup egress is different from this local address (e.g., from the
   primary egress' view).  In other words, it is identified by an
   address different from this local address.

   After obtaining the backup egress, the PLR computes a backup path
   from itself to the backup egress and sets up a backup LSP along the
   path.  It excludes the segment including the primary egress to be
   protected when computing the path.  The PLR sends the primary egress



Chen, et al.             Expires April 18, 2018                 [Page 9]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   a Path message with an SERO for the primary LSP, which indicates the
   backup egress by the final subobject in the SERO.  The PLR puts an
   SERO into the Path messages for the backup LSP, which indicates the
   primary egress.

   The PLR MUST provide one-to-one backup protection for the primary
   egress if the "One-to-One Backup Desired" flag is set in the message;
   otherwise, it MUST provide facility backup protection if the
   "Facility Backup Desired flag" is set.

   The PLR MUST set 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 sets the "local protection available" and the "node
   protection" flag indicating that the primary egress is protected when
   the backup LSP is up and ready for protecting the primary egress.

5.4.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 described in
   RFC 4090 except for that the upstream node as a PLR creates a backup
   LSP from itself to a backup egress in a session different from the
   primary LSP.

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

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

5.4.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 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



Chen, et al.             Expires April 18, 2018                [Page 10]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   egress.  If there 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 is created.

   After getting the backup LSP, the PLR associates the backup LSP with
   a primary LSP for protecting its primary egress.  The PLR records
   that the backup LSP is used to protect the primary LSP against its
   primary egress failure and MUST include an SERO object in the Path
   message for the primary LSP.  The object MUST contain the backup LSP
   ID.  It indicates that the primary egress MUST send the backup egress
   the service label as UA label and the information about forwarding
   the traffic to its destination using the label if there is a service
   carried by the LSP and the primary LSP label as UA label if the label
   is not implicit null.  How UA label is sent is out of scope for this
   document.

   When the PLR detects the failure of the primary egress, it redirects
   the packets from the primary LSP into the backup LSP to backup egress
   and keeps the primary LSP label from the primary egress in the label
   stack if the label is not implicit null.  The backup egress delivers
   the packets to the same destinations as the primary egress using the
   backup LSP label as context label and the labels under as UA labels.

5.4.3.  Signaling for S2L Sub LSP Protection

   The S2L Sub LSP Protection uses a S2L Sub LSP (ref to RFC 4875) as a
   backup LSP to protect a primary egress of a P2MP LSP.  The PLR MUST
   determine to protect a primary egress of a P2MP LSP via S2L sub LSP
   protection when it receives a Path message with flag "S2L Sub LSP
   Backup Desired" set.

   The PLR MUST set up the backup S2L sub LSP to the backup egress,
   create and maintain 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 message along the
   path, receives and processes a Resv message responding to the Path
   message.

   After receiving the 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 the failure of the primary 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.



Chen, et al.             Expires April 18, 2018                [Page 11]


Internet-Draft         RSVP LSP Egress Protection           October 2017


5.4.4.  PLR Procedures during Local Repair

   When the upstream node of a primary egress of an LSP as a PLR detects
   the failure of the primary egress, it follows the procedures defined
   in section 6.5 of RFC 4090.  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 a transit node.

   Moreover, the PLR MUST let the upstream part of the primary LSP stay
   after the primary egress fails through sending Resv message to its
   upstream node along the primary LSP.  The downstream part of the
   primary LSP from the PLR to the primary egress SHOULD be removed.
   When a bypass LSP from the PLR to a backup egress protects the
   primary egress, the PLR MUST NOT send any Path message for the
   primary LSP through the bypass LSP to the backup egress.

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


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 is 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.

6.1.  A Typical Application

   L3VPN is a typical 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.











Chen, et al.             Expires April 18, 2018                [Page 12]


Internet-Draft         RSVP LSP Egress Protection           October 2017


                       *****    *****
     CE1,CE2 in    [R2]-----[R3]-----[L1]             **** Primary LSP
     one VPN      */                 :   \            &&&& Backup LSP
                 */ .................:    \           .... BFD Session
      [CE1]--[R1] ..:                      [CE2]
                 &\                       /
                  &\                     /
                   [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 the failure of L1, R1 sends the traffic from CE1 via
   backup LSP with VPN 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; 4)
   L1 and La is virtualized as one.  This can be achieved by configuring
   a same local address on L1 and La, using the address as a destination
   of the LSP and BGP next hop for VPN traffic.

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

            Figure 3: Locally Protect Egress for L3VPN Traffic

   When R3 detects 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.

6.2.  PLR Procedure for Applications

   When the PLR gets a backup LSP from itself to a backup egress for
   protecting a primary egress of a primary LSP, it includes an SERO
   object in the Path message for the primary LSP.  The object contains



Chen, et al.             Expires April 18, 2018                [Page 13]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   the ID information of the backup LSP and indicates that the primary
   egress sends the backup egress the application traffic label (e.g.,
   VPN label) as UA label when needed.

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 sends the backup egress for
   protecting the primary egress the label as a UA label.  Exactly how
   the label is sent is out of scope for this document.

   When the backup egress receives a UA label from the primary egress,
   it adds a forwarding entry with the label into the LFIB for 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.

   Note that protecting a primary egress of a P2P LSP carrying service
   traffic through a backup egress requires that the backup egress trust
   the primary egress for the information received for a service label
   as UA label.


8.  IANA Considerations

   IANA maintains a registry called "Class Names, Class Numbers, and
   Class Types" under "Resource Reservation Protocol-Traffic Engineering
   (RSVP-TE) Parameters".  IANA is to assign a new C-Type under
   PROTECTION object class, Class Number 37:

   o Egress Protection: C-Type 3

   IANA is to create and maintain a new registry under PROTECTION object
   class, Class Number 37, C-Type 3.  Initial values for the registry
   are given below.  The future assignments are to be made through IETF
   Review.







Chen, et al.             Expires April 18, 2018                [Page 14]


Internet-Draft         RSVP LSP Egress Protection           October 2017


     Value          Name                 Definition
      1       IPv4_PRIMARY_EGRESS      Section 4.1.1
      2       IPv6_PRIMARY_EGRESS      Section 4.1.1
      3       IPv4_P2P_LSP_ID          Section 4.1.2
      4       IPv6_P2P_LSP_ID          Section 4.1.2


9.  Co-authors and Contributors

   1.  Co-authors


      Ning So
      Tata
      E-mail: ningso01@gmail.com


      Mehmet Toy
      Verizon
      E-mail: mehmet.toy@verizon.com


      Lei Liu
      Fujitsu
      E-mail: lliu@us.fujitsu.com


      Zhenbin Li
      Huawei Technologies
      Email: lizhenbin@huawei.com

   2.  Contributors


      Boris Zhang
      Telus Communications
      Email: Boris.Zhang@telus.com


      Nan Meng
      Huawei Technologies
      Email: mengnan@huawei.com


      Prejeeth Kaladharan
      Huawei Technologies
      Email: prejeeth@gmail.com




Chen, et al.             Expires April 18, 2018                [Page 15]


Internet-Draft         RSVP LSP Egress Protection           October 2017


      Vic Liu
      China Mobile
      Email: liu.cmri@gmail.com


10.  Acknowledgement

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


11.  References

11.1.  Normative References

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <https://www.rfc-editor.org/info/rfc4090>.

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <https://www.rfc-editor.org/info/rfc4875>.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
              May 2007, <https://www.rfc-editor.org/info/rfc4873>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

11.2.  Informative References

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1



Chen, et al.             Expires April 18, 2018                [Page 16]


Internet-Draft         RSVP LSP Egress Protection           October 2017


              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, DOI 10.17487/RFC5331, August 2008,
              <https://www.rfc-editor.org/info/rfc5331>.

   [RFC4872]  Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
              Ed., "RSVP-TE Extensions in Support of End-to-End
              Generalized Multi-Protocol Label Switching (GMPLS)
              Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
              <https://www.rfc-editor.org/info/rfc4872>.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
              DOI 10.17487/RFC3473, January 2003,
              <https://www.rfc-editor.org/info/rfc3473>.

   [FRAMEWK]  Shen, Y., Jeyananth, M., Decraene, B., and H. Gredler,
              "MPLS Egress Protection Framework",
              draft-shen-mpls-egress-protection-framework ,
              October 2016.


Authors' Addresses

   Huaimo Chen
   Huawei Technologies
   Boston, MA
   USA

   Email: huaimo.chen@huawei.com


   Autumn Liu
   Ciena
   USA

   Email: hliu@ciena.com


   Tarek Saad
   Cisco Systems

   Email: tsaad@cisco.com




Chen, et al.             Expires April 18, 2018                [Page 17]


Internet-Draft         RSVP LSP Egress Protection           October 2017


   Fengman Xu
   Verizon
   2400 N. Glenville Dr
   Richardson, TX  75082
   USA

   Email: fengman.xu@verizon.com


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

   Email: huanglu@chinamobile.com



































Chen, et al.             Expires April 18, 2018                [Page 18]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/