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, . [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, . 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, . [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, . 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, . [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [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, . [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, . [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, . [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, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . 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, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [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, . 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]