Internet DRAFT - draft-li-teas-serv-driven-co-lsp-fmwk

draft-li-teas-serv-driven-co-lsp-fmwk







Network Working Group                                              Z. Li
Internet-Draft                                                 S. Zhuang
Intended status: Informational                                   J. Dong
Expires: September 18, 2016                          Huawei Technologies
                                                          March 17, 2016


 A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs
                draft-li-teas-serv-driven-co-lsp-fmwk-00

Abstract

   MPLS Traffic Engineering (TE) has been widely deployed to satifisfy
   all kinds of requirements of traffic engineering for transport of
   services.  Complexity of configuration has much negative effect on
   the MPLS TE deployment in the large-scale network.  The document
   identifies the configuration issues for MPLS TE deployment and
   proposes a new mechanism, the service-driven mechanism, by which the
   setup of co-routed MPLS Traffic-Engineered Label-Switched Paths(TE
   LSPs) is triggered by the bidirectional service.  Then the document
   proposes the framework for setting up service-driven co-routed MPLS
   TE LSP for L2VPN and L3VPN.

Requirements Language

   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 [RFC2119].

Status of This Memo

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

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

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

   This Internet-Draft will expire on September 18, 2016.






Li, et al.             Expires September 18, 2016               [Page 1]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


Copyright Notice

   Copyright (c) 2016 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Massive Configuration Issue of TE LSPs  . . . . . . . . .   4
     3.2.  Return Path Issue of BFD for MPLS LSPs  . . . . . . . . .   5
     3.3.  Upgrading Issue of Co-routed Bidirectional LSP  . . . . .   6
   4.  Framework and Procedures  . . . . . . . . . . . . . . . . . .   6
     4.1.  Service-Driven Co-Routed Unidirectional LSPs for L2VPN  .   7
       4.1.1.  Framework . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.2.  Procedures  . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Service-Driven Co-Routed Unidirectional LSPs for L3VPN  .   9
       4.2.1.  Framework . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.2.  Procedures  . . . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Multiprotocol Label Switching (MPLS) traffic engineering (TE) can
   satisfy specific traffic engineering attributes [RFC2702].  MPLS
   TEcan effectively schedule, allocate, and use existing network
   resources to provide bandwidth guarantee and traffic protection for
   transport of services.  MPLS TE is being widely deployed to support
   packet-based services.  Since rich set of traffic engineering
   attributes have to be specified for each LSP and a great deal of
   configuration has to be done as the number of MPLS TE LSPs increases,
   a scalable and simple solution is required to implement TE in a



Li, et al.             Expires September 18, 2016               [Page 2]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   large-scale network and reduce complexity in operation and management
   of TE LSPs.

   LDP LSP setup is topology-driven which is a scalable way to adapt to
   the large-scale network.  The similar way cannot be used for MPLS TE
   since the traffic engineering attributes should be specified for MPLS
   TE LSP which is not necessary for LDP LSP.  On the other hand, MPLS
   TE LSP is always setup to bear specific services such as L3VPN and
   L2VPN.  That is, MPLS TE LSPs will not be setup aimlessly which is
   always inevitable for MPLS topology-driven LSP if there is no complex
   policy applied on it.  So it is a natural way to combine setup of
   MPLS TE LSP with the service it bears.  Setup of MPLS TE LSP can be
   triggered automatically by the service instead of explicitly
   configuring each MPLS TE LSP and corresponding traffic engineering
   attributes.  We call this method as service-driven comparing to
   topology-driven.  Moreover the service-driven method has much
   advantage in the process of setting up co-routed TE LSPs.  The
   service transported by MPLS TE LSPs is always bi-directional.  The
   characteristic can be utilized to setup the forward MPLS TE LSP and
   the co-routed reverse MPLS TE LSP.

   This document describes the framework of automatic setup of co-routed
   MPLS TE LSPs on demand of L2VPN and L3VPN services.  The mechanism
   can facilitate the provisioning of services and the TE LSPs greatly.

2.  Terminology

   This document uses terminology from the MPLS architecture document
   [RFC3031], the RSVP-TE protocol specification [RFC3209] which
   inherits from the RSVP specification [RFC2205] and the Provider
   Provisioned VPN terminology document [RFC4026].

   The document introduces two new concepts by which PEs of VPN can be
   generally categorized into two types:

   o  Active PE: the PE triggers the setup of the LSPs and informs the
      remote PE;

   o  Passive PE: the PE complies with the Active PE's suggestion to set
      up LSPs.

   In this document, the terminology of "tunnel" is identical to the "TE
   Tunnel" defined in Section 2.1 of [RFC3209], which is uniquely
   identified by a SESSION object that includes Tunnel end point
   address, Tunnel ID and Extended Tunnel ID.  The terminology "LSP" is
   identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209],
   which is uniquely identified by the SESSION object together with




Li, et al.             Expires September 18, 2016               [Page 3]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   SENDER_TEMPLATE (or FILTER_SPEC) object that consists of LSP ID and
   Tunnel end point address.

3.  Problem Statement

3.1.  Massive Configuration Issue of TE LSPs

   Deployment MPLS TE in a large-scale networks may require
   configuration of a potentially large number of TE LSPs.

                   ----------------
                  /                \
                 /                  \
                /                    \
   +------+   +----+    Access     +----+
   |eNodeB|---|CSG1|    Ring 1     |ASG1|-------------
   +------+   +----+               +----+             \
                \                    /                 \
                 \                  /                   +----+    +---+
                  \             +----+                  |RSG1|----|RNC|
                   -------------|    |    Aggregate     +----+    +---+
                                |ASG2|      Ring          |
                   -------------|    |                  +----+    +---+
                  /             +----+                  |RSG2|----|RNC|
                 /                  \                   +----+    +---+
                /                    \                 /
   +------+   +----+     Access     +----+            /
   |eNodeB|---|CSG2|     Ring 2     |ASG3|------------
   +------+   +----+                +----+
               \                     /
                \                   /
                 \                 /
                  -----------------
                 Figure 1 Mobile Backhaul Network

   Figure 1 shows an example of the mobile backhaul network.  Mobile
   multimedia devices such as smartphones are ubiquitous now which runs
   a wide variety of bandwidth-intensive applications and causes
   unprecedented growth in mobile data traffic.  In order to cope with
   the growth, more cell sites are introduced into the network: more LTE
   eNodeBs and associated Cell Site Gateways(CSGs) are added in the
   networks.  This causes the network scale expands fast and more and
   more MPLS TE tunnels need setup between Cell Site Gateways(CSGs)
   which connect the eNodeBs and RNC Site Gateways(RSGs) which connect
   the RNCs.

   Typically, we assume that:




Li, et al.             Expires September 18, 2016               [Page 4]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   1.  There are 1,000 CSGs need to connect to one RSG.

   2.  There are three types of bi-directional services transported
   between one CSG and one RSG.  Each type of service needs one VPN and
   one TE tunnel.

   3.  There are 10 command lines to configure necessary attributes for
   each MPLS TE LSP.

   So in one RSG it may take 30,000 command lines to set up MPLS TE
   LSPs.  And all CSGs need another 30,000 commands to set up MPLS TE
   LSPs to one RSG.  The huge configuration work is not only time
   consuming but also prone to mis-configuration.  Hence a mechanism to
   set up MPLS TE LSPs automatically is desirable which can
   significantly reduce complexity of MPLS TE configuration.

3.2.  Return Path Issue of BFD for MPLS LSPs

   |                              |
   |<--------Dynamic BFD--------->|
   |                              |
   |   (1) TE Primary LSP         |
   |----------------------------->|
   |   (2) TE Backup LSP          |
   |----------------------------->|
   +----+   +--+      +--+   +----+
   | PE1|===|P1|======|P2|===| PE2|
   +----+   +--+      +--+   +----+
   |   (3) IP Path (Return Path)  |
   |<-----------------------------|

   Figure 2: BFD for TE LSPs Scenario

   As shown in Figure 2, BFD for MPLS LSPs ([RFC5884]) can be used to
   detect the possible failure fast which can trigger traffic switch
   between the primary LSP and the backup LSP.  When BFD for MPLS LSPs
   is deployed, the return path may take an IP path which is different
   from the forward path.  The failure that happens in the return path
   may cause wrong traffic switch.

   In order to solve the return path issue of BFD for MPLS LSPs, it has
   to be guaranteed that the forward path and the return path must be
   co-routed.  For MPLS TE LSPs the explicit path has to be configured
   for the forward LSP and the return LSP.  In addition, another
   configuration has to be introduced to bind the return BFD traffic
   corresponding to the forward BFD traffic to the right return MPLS TE
   LSP at the ingress node or the egress node.  This will deteriorate
   the configuration work described above.  Morerover, if the forward



Li, et al.             Expires September 18, 2016               [Page 5]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   path changes, the return path may not change accordingly owing to
   statically binding the forward path and the return path.  It will
   cause that the return path issue of BFD for MPLS LSPs happens again.

3.3.  Upgrading Issue of Co-routed Bidirectional LSP

   The co-routed bidirectional LSP is defined in [RFC3945].  If co-
   routed bidirectional LSP is used, the return path is not necessary to
   configure and the return path issue of BFD for LSPs can be solved
   naturally.  This can simplify operation and management for Service
   Providers.  But it is still necessary to configure each LSP.  On the
   other hand, the unidirectional MPLS TE LSPs have been deployed widely
   and it is difficult for the service providers to upgrade all possible
   routers to support co-routed bidirectional LSPs.

4.  Framework and Procedures

   MPLS TE LSPs depend heavily on manual configuration.  So some auto
   provision methods (e.g. auto mesh [RFC4972]) have been proposed.
   This document proposes a new mechanism, the service-driven mechanism,
   to reduce the operation cost of MPLS TE networks.

   It is well known that LDP LSP setup is topology-driven which is a
   scalable way to adapt to the large-scale network.  The similar way
   cannot be used for MPLS TE since the traffic engineering attributes
   has to be specified for the MPLS TE tunnel.  On the other hand, MPLS
   TE LSP is always setup to bear specific services such as L3VPN and
   L2VPN.  That is, MPLS TE LSPs will not be setup aimlessly which is
   always inevitable for MPLS topology-driven LSP if there is no complex
   policy applied on it.  So it is a natural way to trigger MPLS TE LSP
   setup by the service instead of explicitly configuring each LSP.  We
   call this method as service-driven comparing to topology-driven.  In
   fact BGP-based MVPN ([RFC6513] and [RFC6514]) provides an example of
   service-driven method which can trigger P2MP TE LSP setup after MVPN
   membership auto-discovery.

   The service-driven method also has much advantage in the process of
   setting up co-routed MPLS TE LSPs.  The service transported by MPLS
   TE LSPs is always bi-directional.  The characteristic can be utilized
   to setup the forward MPLS TE LSP and the co-routed reverse MPLS TE
   LSP.  This section describes the framework and procedures of setting
   up the co-routed MPLS TE LSPs.  The method needs the signaling of the
   service advertises the tunnel information between PEs.  PEs of VPN
   can be generally categorized into two types: Active PE and Passive
   PE.  The Passive PE can set up the reverse LSP to the Active PE based
   on RRO information of the forward LSP which is from the Active PE to
   the Passive PE.  Thus the path of the reverse LSP can be co-routed
   with the path of the forward LSP.



Li, et al.             Expires September 18, 2016               [Page 6]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   Service-driven co-routed MPLS TE LSP has following advantages:

   1) Set up LSPs on demand and save massive configuration effort.

   2) Reuse existing mechanism as much as possible.  It only needs
   upgrading of PEs instead of whole network upgrading.

4.1.  Service-Driven Co-Routed Unidirectional LSPs for L2VPN

4.1.1.  Framework

   Active PE              Passive PE
   PE1                           PE2
   |                              |
   |<----Signaling Tunnel Info--->|
   |                              |

   |       TE LSP1 for PW         |
   |----------------------------->|
   |             PW               |
   |<---------------------------->|
   |       TE LSP2 for PW         |
   |<-----------------------------|
   +----+   +--+      +--+   +----+
   | PE1|===|P1|======|P2|===| PE2|
   +----+   +--+      +--+   +----+
   |                              |

   Figure 3: Framework of L2VPN Driven TE LSP

   L2VPN, as defined in [RFC4664], is a proven and widely deployed
   technology.  Figure 3 shows a framework for co-routed MPLS TE LSPs
   driven by L2VPN service.  L2VPN is provisioned on PEs and the PW is
   setup between a pair of PEs.  The pair of PEs for a specific PW will
   be identified as the Active PE and the Passive PE respectively.  The
   Active PE triggers the set up of the forward LSP (TE LSP1) to the
   Passive PE and advertises the tunnel information to the Passive PE.
   According to the information advertised by the Active PE, the Passive
   PE will set up the reverse LSP (TE LSP2) which is co-routed with the
   forward LSP.

4.1.2.  Procedures









Li, et al.             Expires September 18, 2016               [Page 7]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


                  PE1                                         PE2
                  | (1) Active/Passive role election          |
                  | (Here PE1 is elected as Active PE)        |
                  |<----------------------------------------->|
                  |                                           |

              Active PE                                   Passive PE

     (2)PE1's PW drives RSVP-TE           (2) PE2 waits for Tunnel info
      to create TE LSP(e.g. LSP1)             advertised from PE1

                  |(3) PE1 advertises LSP1 Tunnel info        |
                  |    to PE2 through PW signaling            |
                  |------------------------------------------>|
                  |                                           |

                                 (4) PE2 gets forward Tunnel info from
                                     PE1,
                                     Create TE LSP (e.g. LSP2) according
                                     to RRO information of LSP1,
                                     Binds LSP1 and LSP2 for PW;

                  |(5) PE2 advertises LSP2 Tunnel info to PE1 |
                  |<------------------------------------------|
                  |                                           |

   (6)PE1 binds LSP1 and LSP2 for the PW;

                  |       Co-routed TE LSP Established        |
                  |<----------------------------------------->|
                  |                                           |

       Figure 4: Signaling Procedures of L2VPN Driven Co-Routed TE LSPs

   Figure 4 shows the detailed procedures for L2VPN driven co-routed
   MPLS TE LSPs.  Through the above procedures, the co-routed MPLS TE
   LSPs driven by the PW are established between a pair of PEs.

4.1.2.1.  Active/Passive Role Election

   The Active and Passive roles of PEs can be determined through manual
   configuration or dynamic election between a pair of PEs for a
   specific PW.  When the dynamic election method is used, LSR IDs of a
   pair of PEs between which PW is setup are compared as unsigned
   integers and the PE with the larger value of LSR ID assumes the
   Active role.





Li, et al.             Expires September 18, 2016               [Page 8]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


4.1.2.2.  Signaling Tunnel Information

   In the service-driven co-routed MPLS TE framework for L2VPN, the
   tunnel information needs to be advertised between the Active PE and
   the Passive PE.  The Passive PE uses the tunnel information to get
   corresponding MPLS TE tunnel and RRO information which is used to
   setup the reverse co-routed MPLS TE LSP.
   [I-D.ietf-pwe3-mpls-tp-pw-over-bidir-lsp] defines how the
   bidirectional Tunnel/LSP identifier information is advertised between
   a pair of PEs for PW.  The similar mechanism can be reused for
   advertising MPLS TE tunnel/LSP identifier information for service-
   driven MPLS TE LSPs for L2VPN.

4.1.2.3.  Procedures

   Step 1: Active/Passive role election through signaling between a pair
   of PEs of a PW.  In this case, assume PE1 as Active PE and PE2 as
   Passive PE after election;

   Step 2: As the active role, the PW service on PE1 drives RSVP-TE to
   create the forward TE LSP(e.g.  LSP1).  As the passive role, PE2
   waits for tunnel information advertised by PE1;

   Step 3: PE1 advertises tunnel information of LSP1 to PE2;

   Step 4: PE2 gets tunnel information from PE1 and creates the reverse
   TE LSP (e.g.  LSP2) according to RRO information derived from LSP1.
   PE2 binds LSP1 and LSP2 for the PW;

   Step 5: PE2 advertises tunnel information of LSP2 to PE1;

   Step 6: PE1 binds LSP1 and LSP2 for the PW.

   Through the above procedures, the co-routed MPLS TE LSPs driven by
   the PW are established.

4.2.  Service-Driven Co-Routed Unidirectional LSPs for L3VPN

4.2.1.  Framework












Li, et al.             Expires September 18, 2016               [Page 9]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   Active PE              Passive PE
   PE1                           PE2
   |                              |
   |<----Signaling Tunnel Info--->|
   |                              |

   |       TE LSP1 for L3VPN      |
   |----------------------------->|
   |             L3VPN            |
   |<---------------------------->|
   |       TE LSP2 for L3VPN      |
   |<-----------------------------|
   +----+   +--+      +--+   +----+
   | PE1|===|P1|======|P2|===| PE2|
   +----+   +--+      +--+   +----+
   |                              |

   Figure 5: Framework of L3VPN Driven TE LSP

   L3VPN services are provided by [RFC4110].  Figure 5 shows a framework
   for co-routed MPLS TE LSPs driven by L3VPN service.  L3VPN is
   provisioned on PEs and VPN membership is discovered.

   The pair of PEs for a specific L3VPN will be identified as the Active
   PE and the Passive PE respectively.  The Active PE triggers the set
   up of the forward LSP(TE LSP1) to the Passive PE and advertises the
   tunnel information to the Passive PE.  According to the information
   advertised by the Active PE, the Passive PE will set up the reverse
   LSP (TE LSP2) which is co-routed with the forward LSP.

4.2.2.  Procedures




















Li, et al.             Expires September 18, 2016              [Page 10]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


                 PE1                                         PE2
                 | (1) VPN Membership Auto-Discorvery        |
                 |<----------------------------------------->|
                 |                                           |
                 | (2) Active/Passive role election          |
                 |  (Here PE1 is elected as Active PE)       |
                 |<----------------------------------------->|
                 |                                           |

                 Active PE                                   Passive PE

  (3)PE1's L3VPN drives RSVP-TE          (3) PE2 waits for Tunnel info
     to create TE LSP(e.g. LSP1)             advertised from PE1

                 |(4) PE1 advertises LSP1 Tunnel info        |
                 |    to PE2 through L3VPN signaling         |
                 |------------------------------------------>|
                 |                                           |

                                 (5) PE2 gets forward Tunnel info
                                     from PE1,
                                     Create TE LSP (e.g. LSP2) according
                                     to RRO information of LSP1,
                                     Binds LSP1 and LSP2 for L3VPN;

                 |(6) PE2 advertises LSP2 Tunnel info to PE1 |
                 |<------------------------------------------|
                 |                                           |

  (7)PE1 binds LSP1 and LSP2 for L3VPN;

                 |       Co-routed TE LSP Established        |
                 |<----------------------------------------->|
                 |                                           |

  Figure 6: Signaling Procedures of L3VPN Driven Co-Routed TE LSPs

   Figure 6 shows the detailed procedures for L3VPN to drive the set up
   of co-routed MPLS TE LSPs.  Through the above procedure, the co-
   routed MPLS TE LSPs driven by the L3VPN are established between a
   pair of PEs.

4.2.2.1.  VPN Membership Auto-Discovery

   In order to set up co-routed MPLS TE LSPs in L3VPN, a point-to-point
   connection between any two VRFs of a particular VPN needs to be
   established.  VPN membership auto-discovery should be done firstly




Li, et al.             Expires September 18, 2016              [Page 11]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   and the mechanism defined in [I-D.dong-l3vpn-pm-framework] can be
   used.

4.2.2.2.  Active/Passive Role Election

   After obtaining the VPN membership information via VPN membership
   auto-discovery process, we can identify a pair of VPN members.

   The Active and Passive role of PEs can be determined through manual
   configuration or dynamic election between a pair of PEs for a
   specific L3PVN.  When the dynamic election method is used, LSR IDs of
   a pair of PEs between which existing the pair of VPN members are
   compared as unsigned integers and the PE with the larger value of LSR
   ID assumes the Active role.

4.2.2.3.  Signaling Tunnel Information

   In the service-driven co-routed MPLS TE framework for L3VPN, the
   tunnel information needs to be advertised between the Active PE and
   the Passive PE.  The Passive PE uses the tunnel information to get
   corresponding MPLS TE tunnel and RRO information which is used to
   setup the reverse co-routed MPLS TE LSP.  MP-BGP signaling needs
   extensions to advertise the MPLS TE tunnel/LSP identifier information
   for service-driven MPLS TE LSPs for L3VPN.

4.2.2.4.  Procedures

   Step 1: VPN Membership Auto-Discovery process is done through
   signaling to identify a pair of VPN members;

   Step 2: Active/Passive role election through signaling between a pair
   of PEs of a L3VPN.  In this case, assume PE1 as Active PE and PE2 as
   Passive PE after election;

   Step 3: As the active role, L3VPN service on PE1 drives RSVP-TE to
   create forward TE LSP(e.g.  LSP1), as the passive role, PE2 waits for
   tunnel information advertised by PE1;

   Step 4: PE1 advertises tunnel information of LSP1 to PE2;

   Step 5: PE2 gets tunnel information from PE1 and creates TE LSP (e.g.
   LSP2) according to RRO information derived from LSP1.  PE2 binds LSP1
   and LSP2 for the L3VPN;

   Step 6: PE2 advertises tunnel information of LSP2 to PE1;

   Step 7: PE1 binds LSP1 and LSP2 for the L3VPN.




Li, et al.             Expires September 18, 2016              [Page 12]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   Through the above procedures, the co-routed MPLS TE LSPs driven by
   the L3VPN are established.

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   This document does not change the security properties of L2VPN &
   L3VPN.

7.  References

7.1.  Normative References

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

   [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,
              <http://www.rfc-editor.org/info/rfc3209>.

7.2.  Informative References

   [I-D.dong-l3vpn-pm-framework]
              Dong, J., Li, Z., and B. Parise, "A Framework for L3VPN
              Performance Monitoring", draft-dong-l3vpn-pm-framework-03
              (work in progress), October 2014.

   [I-D.ietf-pwe3-mpls-tp-pw-over-bidir-lsp]
              Chen, M., Cao, W., Takacs, A., and P. Pan, "LDP extensions
              for Pseudowire Binding to LSP Tunnels", draft-ietf-pwe3-
              mpls-tp-pw-over-bidir-lsp-03 (work in progress), September
              2014.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <http://www.rfc-editor.org/info/rfc2205>.

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, DOI 10.17487/RFC2702, September 1999,
              <http://www.rfc-editor.org/info/rfc2702>.



Li, et al.             Expires September 18, 2016              [Page 13]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <http://www.rfc-editor.org/info/rfc3031>.

   [RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Architecture", RFC 3945,
              DOI 10.17487/RFC3945, October 2004,
              <http://www.rfc-editor.org/info/rfc3945>.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026,
              DOI 10.17487/RFC4026, March 2005,
              <http://www.rfc-editor.org/info/rfc4026>.

   [RFC4110]  Callon, R. and M. Suzuki, "A Framework for Layer 3
              Provider-Provisioned Virtual Private Networks (PPVPNs)",
              RFC 4110, DOI 10.17487/RFC4110, July 2005,
              <http://www.rfc-editor.org/info/rfc4110>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC4664]  Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
              2 Virtual Private Networks (L2VPNs)", RFC 4664,
              DOI 10.17487/RFC4664, September 2006,
              <http://www.rfc-editor.org/info/rfc4664>.

   [RFC4972]  Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
              Previdi, S., Psenak, P., and P. Mabbey, "Routing
              Extensions for Discovery of Multiprotocol (MPLS) Label
              Switch Router (LSR) Traffic Engineering (TE) Mesh
              Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007,
              <http://www.rfc-editor.org/info/rfc4972>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <http://www.rfc-editor.org/info/rfc5036>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <http://www.rfc-editor.org/info/rfc5880>.







Li, et al.             Expires September 18, 2016              [Page 14]

Internet-Draft      A Framework for SD Co-Routed LSPs         March 2016


   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
              June 2010, <http://www.rfc-editor.org/info/rfc5884>.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <http://www.rfc-editor.org/info/rfc6513>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <http://www.rfc-editor.org/info/rfc6514>.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Shunwan Zhuang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com


   Jie Dong
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com










Li, et al.             Expires September 18, 2016              [Page 15]