Network Working Group Z. Li Internet-Draft Huawei Technologies Intended status: Informational March 13, 2016 Expires: September 14, 2016 Comparison between Segment Routing and LDP/RSVP-TE draft-li-spring-compare-sr-ldp-rsvpte-01 Abstract Segment Routing has been proposed to cope with the use cases in traffic engineering, fast re-reroute, service chain, etc. This document is to compare Segment Routing with the existing LDP and RSVP-TE. Through the comparison the challenges are clarified for the Segment Routing when deploy in the existing MPLS network. 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 14, 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 Li Expires September 14, 2016 [Page 1] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 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. General Challenges for Segment Routing . . . . . . . . . . . 3 3.1. Issues Proposed by Depth of Label Stack . . . . . . . . . 3 3.2. Issues Proposed by Multicast . . . . . . . . . . . . . . 3 3.3. Issues Proposed by Growing States . . . . . . . . . . . . 4 3.4. Issues Proposed by Deployment in Distributed Environment 4 4. Comparison between SR-BE Path and LDP . . . . . . . . . . . . 4 4.1. Ordered Mode . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Proxy Egress . . . . . . . . . . . . . . . . . . . . . . 6 4.3. DoD Mode . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Routing Dependency . . . . . . . . . . . . . . . . . . . 8 4.5. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 8 4.6. Loop Prevention . . . . . . . . . . . . . . . . . . . . . 9 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 5. Comparison between SR-TE path and RSVP-TE . . . . . . . . . . 9 5.1. MPLS TE Hot-standby . . . . . . . . . . . . . . . . . . . 9 5.2. Loose Explicit path . . . . . . . . . . . . . . . . . . . 10 5.3. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Path Recording . . . . . . . . . . . . . . . . . . . . . 12 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 12 5.6. Other MPLS TE Requirements . . . . . . . . . . . . . . . 12 6. Challenges of Interoperability between SR and LDP/RSVP-TE . . 12 6.1. Interoperability between SR and LDP . . . . . . . . . . . 12 6.2. Interoperability between SR and RSVP-TE . . . . . . . . . 14 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Segment Routing has been proposed to cope with the use cases in traffic engineering, fast re-reroute, service chain, etc. The signaling of Segment Routing is based on the extensions of IGP. This document is to compare Segment Routing with the existing LDP Li Expires September 14, 2016 [Page 2] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 [RFC5036] and RSVP-TE[RFC3209].Through the comparison the challenges are clarified for the Segment Routing when deploy in the existing MPLS network. 2. Terminology SDN: Software-Defined Network SR: Segment Routing SR-path: Segment Routing Path SR-BE path: Segment Routing Best-Effort Path SR-TE path: Segment Routing Traffic Engineering Path 3. General Challenges for Segment Routing 3.1. Issues Proposed by Depth of Label Stack In segment routing, forwarding packets need to be pushed a SR header with a list of segments(labels). If MPLS forwarding plane is adopted, the depth of label stack may become the challenges for some type of devices. The challenges proposed by the depth of label stack include: 1) Upgrading hardware of existing devices; 2) If not upgrade, when do path calculation in control plane, it must be careful not to make the segment routing path to exceed the capability of forwarding plane. In other word, the depth of label stacks becomes one more constraint for the path calculation which has much effect on the scalability of the segment routing path. 3) If upgrade forward plane and control plane to make segment routing scalable enough, there will be payload efficiency issue and MTU issue. That is, the size of the SR header will reduce the efficiency of payload. 3.2. Issues Proposed by Multicast Multicast proposes more challenge for the segment routing. Now MPLS- based multicast solutions ( P2MP TE [RFC4875] and mLDP [RFC6388]) are mature after many years' development. Moreover IP network is widely used to bearing multiple services including unicast, multicast, etc. Segment routing is to replace LDP/RSVP-TE to simplify network operation and maintenance. In fact, it is only able to replace P2P Li Expires September 14, 2016 [Page 3] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 LDP/RSVP-TE. Thus there will be the case for multi-service bearing IP network: IGP is to introduce to cope with label-based unicast service while mLDP/P2MP TE has to be kept to bear multicast service. This will increase complexity of operation and management of the IP network. 3.3. Issues Proposed by Growing States One major advantage of segment routing is that the states are only maintained at the head-end and no state is necessary to be maintained at mid-points and tail-ends. As the development of segment routing, there will be more segments which will be used or multiple purposes such as any cast segment, service chain, etc other than limited node segment and adjacency segment. There may be more states in the segment-routing-based network. And the flooding feature of IGP will make all nodes in the network have to maintain these states which may be unnecessary to some nodes. The growing states will also have effect on the scalability of the network. 3.4. Issues Proposed by Deployment in Distributed Environment In the distributed environment there will be some challenges for the deployment of segment routing: 1) Possible configuration introduced by policy control or path control. After the segments are flooded in the distributed network, in some scenarios there will be a lot of configuration work for the deployment of segment routing. For example, for SR-TE path, each hop or several hops have to be specified in the ingress node. The configuration work is the same as specifying the explicit path for the existing MPLS TE LSP. 2) Complex label allocation method of segment routing. The existing label allocation method has to reserve SRGB, flood the SRGB, specify the unique Segment Index and map the Segment ID to the label. The method is complex and not scalable. When deploy in the network, it must be careful to choose the range of SRGB. If the range is too big, it will have much effect on the scalability of service since it may waste the label space. If it is small, there may introduce the upgrading issues to change the label range as the increase of segment-routing-based service. 4. Comparison between SR-BE Path and LDP Li Expires September 14, 2016 [Page 4] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 4.1. Ordered Mode (Non-SR) S11-----------S12----------S13---------S14 | | | | | | | | | | | | S21-----------S22----------S23---------S24 As above topology, there are 8 nodes and assume all the metics of the links are 1 and VPNs are deployed on S11/S21/S14/S24. If LDP is used as the tunnel for VPN on S11/S14, since LDP can support the ordered mode. The LSP for the S14 will be setup as the order S14->S13->S12->S11 for distribution of label mapping. And the shortest path for routes to S14 is also S11->S12->S13->S14. So the end-to-end LSP to S14 is setup. If one node (e.g. S13) does not support LDP, according to LDP ordered mode, the end-to-end LSP cannot setup since S12 does not receive the label mapping from the exact nexthop of the route, S13 and it will not distribute the label mapping to S11. And the result is that the VPN on S11 cannot take the LSP since the LSP cannot setup on S11. If SR-BE path is used as the tunnel for VPN on S11/S14 and assume the S13 cannot support the SR, according to my understanding, there will be an SR-BE path for the destination S14 which is interrupted at S12. This is similar as the independent mode of LDP. If this VPN takes this SR-BE Path at S11, the VPN traffic will be dropped at S12. Comparing with LDP Ordered mode, this means more useless traffic will enter into the network which may have more negative effect on the normal traffic. For LDP, there are two LSP advertisement modes: -- Ordered mode: Depend on the egress and the downstream node -- Independent mode: Depend on the downstream node. In fact, SR is based on IGP and introduces one totally different mode which we called as flooding mode. -- Flooding mode: Depend the node's self In segment routing, the label binding for the nodes in segment routing is stable, after the label binding are flooded, for every nodes in the network, once there are the routes to the destination nodes address, the ingress LSP can be setup to be used for VPN, etc. For LDP independent, even if the route is available, it has to wait Li Expires September 14, 2016 [Page 5] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 for the label mapping from the downstream to setup the ingress LDP to be used for VPN, etc. Comparing the three modes, the flooding mode is more independent. This means it is easiest to set up the interrupted LSP and leak the useless traffic into the network which will have negative effect on the normal traffic in the network. 4.2. Proxy Egress PE11--------ASBR11--------ASBR21-------PE21 | | | | | AS1 | | AS2 | | | | | PE12--------ASBR12--------ASBR22-------PE22 One use case of LDP proxy egress, Inter-AS VPN Option C, is shown in the above figure. In this case, the label BGP(RFC3107) can advertise the label route for PE21 and PE22 from the ASBR in AS2 to the ASBR in AS1. Some carriers prefers to use label BGP to go on to advertise the label route to PE11 and PE12. But some carriers do not like full mesh BGP peers and three layer label for the traffic, they would redistribute the BGP routes to IGP at ASBR11/ASBR12 and depend on LDP to setup LDP LSP for the prefix PE21/PE22 in the AS1. For the use case if the SR is adopted, there may propose following challenges: 1. In order to support proxy egress for SR-BE path, we have to configure the SID/label for the proxy egress nodes. But there may be multiple ASBRs in the scenarios. It has be to be determined which ASBRs should be chosen to configure these SID/label bindings. 2. If there are 10,000 proxy egress addresses proposed by seamless MPLS, this means we have to configure 10,000 SID/label bindings on one ASBR. The huge configuration work is difficult to be accepted . 3. Since the proxy egress is learned from outside of the network, if configure the static the SID/label for a specific proxy egress, but the proxy egress is not learned, the SID/label is wasted. If not configured, but the proxy egress is learned, the SR-BE path does not work. The dynamic change of proxy egress will propose the challenge on the configuration of SID/label. In fact, there are more usecases of proxy egress: 1. C & C: Proxy egress for the VPN routes Li Expires September 14, 2016 [Page 6] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 2. Seamless MPLS: Proxy egress for the LDP DoD 3. Some usecases which needs LDP node and Non-LDP node coexists. If these proxy egress scenarios cannot be supported by segment routing, there will the co-existence of LDP for Proxy Egress and SR for actual egress. It will be too complex and SR is totally unnecessary. In addition, TI-FRR for the proxy egress case cannot be supported either. 4.3. DoD Mode +-------+ +-------+ +------+ +------+ | | | | | | | | +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN / | | /| | | | | | +----+/ +-------+\/ +-------+ +------+ /+------+ | AN | /\ \/ | +----+\ +-------+ \+-------+ +------+/\ +------+ \ | | | | | | \| | +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN | | | | | | | | +-------+ +-------+ +------+ +------+ static route ISIS L1 ISIS L2 LDP DoD LDP DU LDP DU <-Access-><--Aggregation Domain--><---------Core---------> Seamless MPLS has been proposed as one important architecture for network integration. As show in the above the figure. In the access network between AN and AGNs, static route and LDP DoD are adopted. There even more features related LDP in the scenarios: LDP proxy egress on AGN and Inter-area extensions of LDP. Besides the challenge of proxy egress for SR explained in the above section, there may propose the other two issues: 1. LDP DoD: In this scenarios, LDP DoD is adopted to set up LSP on demand which can controlled the number of LSP. The control can be applied in the ingress node combing with the service supported(e.g. in the case, if the configured LDP remote peer for PW service can trigger LDP DoD to send label request in AN). But for SR, its floods the label mapping in the network. If hope to control the setup of LSP, the complex policy must be applied on multiple nodes. 2. [RFC5283] proposes the LDP inter-area extensions. That is, when search routes for the received label mapping, longest-match method can also be adopted besides the exact match. For SR, it should also Li Expires September 14, 2016 [Page 7] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 determine which method it depends on when loop up routes for the label binding. 4.4. Routing Dependency For LDP, when search route for the destination address which is the FEC of the label mapping, it should search the FIB in which the routes are selected from the static route, OSPF, ISIS, BGP, etc based on the preferences. Now there is one question for SR-BE path, for example, if the SID/Label is advertised through OSPF, what type of routes should the label mapping depend on when setup the SR-BE path? There may be two choices: 1. Only depend on the OSPF's own route; 2. Like the LDP, depends on the selected route. Option 1 should not be the right choice. For example, we configure static routes for all nodes along the path to a specific node which can be totally different from the OSPF routes to the node. If the static route has higher priority than the OSPF and the SID/label is advertised by OSPF depends on OSPF routes, there will be the inconsistency between the SR-BE path and the route path. If the option 2 is adopted, it cannot be assumed that the label mapping and the route are in the same LSDB which can be easily synchronized. There are two challenges: 1. The direct effect for the OSPF is that at the beginning it just downloads it routes to the RIB for the route selection. That is, it is the source of the route selection. But now owing to SR-BE path, it has to depend on the result of the route selection. 2. OSPF SR-BE path may depend on the routes from the static route, ISIS, BGP, etc. It is claimed that the SR can remove the IGP-LDP sync. There may be the possible risk to have to introduce the sync between OSPF and other routing protocols. 4.5. MTU Issues There will be the scenarios that the backup path is provided for the primary path in the existing MPLS network. For segment routing, since the label stack for the primary path and the backup path may be different. As the increase of the difference between the paths, the risk will increase that the traffic forwarded in one path will be dropped in another path owing to the limitation of the MTU. For SR- Li Expires September 14, 2016 [Page 8] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 BE path, it has to be taken into account for the case of topology- independent LFA. Besides the issue, LDP can support the path MTU to track the MTU information along the LSP through signaling. Then the reasonable MTU can be adopted in the ingress node for the LSP. For SR-BE path, the ingress node could not collect the MTU information and there will be the risk that the packets may be dropped by the transit nodes along the SR path. 4.6. Loop Prevention For LDP, there is loop prevention mechanism when setup LSP. For Segment Routing, the SR path is always setup at the ingress node. It is difficult to detect the possible loop in the network. If the loop of route happens, the loop prevention mechanism may prevent LDP to setup LSP. But for the segment routing, once the ingress node downloads the forwarding entry and the traffic will experience the loop. 4.7. Error Handling For LDP, there is the error notification mechanism based on the LDP notification message. Based on the error notification, the nodes along the LSP can take actions against the possible errors. But for SR, there is no such information communicated among the nodes along the SR Path. The result will be that once the packet is forwarded by the ingress node, they may experience the possible errors which may be prevented by the negotiation in the control plane. 5. Comparison between SR-TE path and RSVP-TE 5.1. MPLS TE Hot-standby 1 1 1 1 S11-----------S12----------S13---------S14---------S15 | | | | | 1| 1| 1| 1| 1| | | | | | S21-----------S22----------S23---------S24---------S25 4 4 4 4 MPLS TE hotstandy is always adopted in the MPLS for the traffic protection. In order to avoid one node/link failure cause both the primary path and the backup path becomes down, it is required that the primary path and the backup path should be totally disjointed. Li Expires September 14, 2016 [Page 9] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 If the design principle should be also applied to the SR-TE path, taking into account the above topology (the numbers near the line represent the metrics of the links), in order to guarantee the disjoint of the primary path and the backup path, the label stack [ S22 SL(S22/S23) S23 SL(S23/24) S24 SL(S24/S25) S15 ] (SL means the link segment between the two neighboring nodes) must be specified for the hotstandby path. So in the case there maybe more labels to be encapsulated for the packets forwarded through the hot-standby path. It may be easy to exceed the hardware limitation or cause the low efficient payload. 5.2. Loose Explicit path S4---S5 / \ S1---S2---S3 S8---S9---S10 \ / S6---S7 For MPLS TE, there are two types of explicit paths: strict and loose. Even for the loose hop, the ingress node will calculate all the hops to the loose hop. And the MPLS TE path is independent from the routing, this means even if the route change, the MPLS TE path to the loose hop can be kept. For example, as shown in the above figure, if the ingress S1 configures the loose hop S8 to the destination S10, it will calculate the path S1->S2->S3->S4->S5->S8->S9->S10. If the metric changes for the link between S3 and S4 and make the shortest route path to S8 from the S3->S4->S5->S8 to S3->S6->S7->S8. But the exiting MPLS TE path will not change accordingly. For SR-BE Path, if the loose hop is configured, there will be two possible choices: Option 1. Same as the existing MPLS TE. If the option is adopted, there will be following challenges: 1) This means the loose hop cannot reduce the label stack for the SR- TE path. It need more labels to be encapsulated after calculating the whole path and representing each hop with node label or adjacency label. The deep depth of the label stack may exceeds the hardware limitation or cause low efficiency payload. 2) More challenges can be proposed from the inter-area behavior. If PCE is not adopted, if the ingress node has to only specify the ABRs as the loose hop to the destination for inter-area, for MPLS TE, the ingress node can acquire the end-to-end path info through RRO. But since there is no RRO-like mechanism in IGP, it is impossible for SR- Li Expires September 14, 2016 [Page 10] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 TE path to get the end-to-end path info. This means the ingress node cannot get the whole label stack info to determine the whole SR-TE path. Option 2. Limited labels for the loose hop. For example, since only loose hop S8 is specified, then the label stack for the SR-TE path to the S10 is [S8 S10]. That is, two layers of labels is enough. This method can avoid the deep label stack issue. But it will introduce other issues. In fact, for the SR-TE path, it mixes the route path and the TE path together. There may be following issues: 1) The route change will have effect on the SR-TE path. If the routes to the S8 is changes, the SR-TE path to the S10 will change accordingly. 2) For the ingress node, from the point of the network maintenance view, it loses the control on the end-to-end path. That is, the end- to-end path is unknown to the ingress node. 3) If there is load balance for the route, for example, there are two equal paths to S8 as the above topology: S3->S4->S5->S8, S3->S6->S7->S8.If BFD is enabled for the SR-TE path, the BFD packets and the real traffic may go through different path. There will be the possibility that BFD will detect the wrong path and may cause further problem such as the wrong traffic switch. 5.3. MTU Issues 1 1 1 1 S11-----------S12----------S13---------S14---------S15 | | | | | 1| 1| 1| 1| 1| | | | | | S21-----------S22----------S23---------S24---------S25 4 4 4 4 Still take the topology in the section 5.1 as the example. No matter the loose explicit path or the strict explicit path, assume the MTU is the same, since the depth of the label stack for the primary path and the backup path is different. There is the risk that the effective payload may transmit through the primary path, but may be fragmented or dropped in the backup path. As the difference between the label stacks of the primary path and the backup path increase, the risk will increase. From the case, we can deduce that the risk may exists for any scenarios in which the same traffic may switch from one SR path to Li Expires September 14, 2016 [Page 11] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 the other SR path. The SR path includes SR-TE path such as MPLS TE hotstandby/reoptimization and SR-BE path such as TI-FRR. Besides above issues, RSVP-TE can support the path MTU to track the MTU information along the LSP through signaling. Then the reasonable MTU will be adopted in the ingress node for the LSP. For SR-TE path, the ingress node could not collect the MTU information and there will be the risk that the packets may be dropped by the transit nodes along the SR path. 5.4. Path Recording Path recording functionality provided by the RRO in RSVP-TE can be used as the path information maintenance, loop prevention, path pinning, fast reroute, etc. When IGP is used as the signaling for Segment Routing, lack of the path recording functionality will cause the corresponding applications can not be implemented. 5.5. Error Handling For RSVP-TE, there is the error notification mechanism based on the RSVP-TE PathErr/Resv messages. Based on the error notification, the nodes along the LSP can take actions against the possible errors. But for SR, there is no such information communicated among the nodes along the SR Path. The result will be that once the packet is forwarded by the ingress node, they may experience the possible errors which may be prevented by the negotiation in the control plane. 5.6. Other MPLS TE Requirements [RFC2702] defines the MPLS TE requirements. SR-TE may fulfill the explicit path requirement, but the other MPLS TE requirements can not be satisfied. 6. Challenges of Interoperability between SR and LDP/RSVP-TE 6.1. Interoperability between SR and LDP The first case is proposed as the following scenario: SR LDP LDP SR S11-----------S12----------S13---------S14---------S15 | | | | | | | | | | | | | | | S21-----------S22----------S23---------S24---------S25 Li Expires September 14, 2016 [Page 12] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 Assume all other nodes support SR and only S12/S13/S14 support LDP. If the LSP stitching is adopted, there will be following process: -- In S12, the egress SR-BE path will stitch the ingress LDP LSP, If the link between the S12 and S13 fails firstly, then restored, the IGP-LDP sync is also necessary. -- In S14, the egress LDP LSP will stitch the ingress SR-BE path. Moreover, if the scenario is changes to the opposite way, that is all other nodes support LDP and only S12/S13/S14 support SR, it has to introduce the proxy egress for SR-BE path which has explained in the previous analysis that it will be difficult to be supported by the SR. From the case, it can be seen that the SR-LDP interoperability issue is more difficult that the IGP-LDP sync which could be removed by SR as claimed. The second case is proposed as the following scenario: LDP LDP S11-----------S12----------S13 | | SR| |SR | | S21-----------S22----------S23 SR SR Assume S11/S12/S13 support LDP and S11/S21/S22/S23/S13 support SR. If the primary path to S13 is S11->S12->S13 is based on LDP LSP. In order to achieve the 100% network coverage, LDP remote peer can be set up between S11 and S13 to advertise label mapping directly from the S13 to S11. The backup path can be: the backup LDP label goes through the SR path S11->S21->S22->S23->S13. This means that the Remote LFA must co-exist with TI-LFA. From the case, it can be seen that the combined FRR solutions is more complex than one of these FRR solutions. From the previous analysis, we can see that some of the existing LDP scenarios cannot be supported by SR-BE path. This means if SR is adopted, it has to co-exist with LDP in these scenarios. Besides the co-existence of SR and LDP, for the legacy network using LDP, if SR is adopted to replace the LDP, it is also inevitable that the SR has to co-exist with LDP. If these scenarios happens, there will be a mess of solutions in the network. Li Expires September 14, 2016 [Page 13] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 In the history of deployment of LDP, though there are different label advertisement modes, label distribution modes and label retention modes, in order to simplify the network operation and maintenance, only one type of label advertisement mode, one type of label distribution mode and one type of one label retention mode are adopted. But for SR, it works in the totally different way from the LDP in many aspects. If SR and LDP co-exist in one network and the behaviors could not be unified, the mess of the solutions is inevitable. Taking into account SR's interworking with LDP's two LSP advertisement modes, two LSP distribution modes, two label retention modes, two types of LDP peer as well as new IGP-LDP stitching/hierarchy/sync and the interworking LFA/R-LFA FRR for LDP with the TI-LFA for SR, there will introduce huge details and much of the details maybe implementation specific which will propose potential risk of the interoperability. Moreover, based on the analysis in the previous sections, there are some requirements of LDP which cannot be supported by SR-BE path yet now. If these issues are not solved, the introducing of SR in the LDP network will also affect the normal process of LDP. According to the above analysis, it is recommended for the network transition that if there is the scenario in which SR-BE path is truly applicable, it is better to replace the existing LDP all at once to avoid the possible interoperability issue. 6.2. Interoperability between SR and RSVP-TE Regarding the interoperability of SR-TE path with RSVP-TE, the general problem is that both SR-TE path and RSVP-TE cannot support proxy egress now and the stitching would not work at all. The only way is just to replace the RSVP-TE LSP with the SR-TE path if the SR- TE path is truly applicable. 7. Summary From the previous analysis, we can see that in the traditional LSP, the LSP setup is negotiated through the signaling between the upstream node and the downstream node. During the negotiation, it is not only to set up the forwarding entry for the purpose of reachability, but also includes many aspects (we can call them as the operation and maintenance of the LSP. ) such as the end-to-end connectivity verification, the loop prevention, path MTU, negotiation, path recording, error notification and handling, etc. Though label stacks based on SR can satisfy the requirement of the reachability, the requirements of the operational and maintenance for the traditional LSP still exist. Taking into account that the flooding mode of the IGP, it stops the communication between the Li Expires September 14, 2016 [Page 14] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 nodes along the path, the work may become more complex. According to the past experience, the possible ways may be as follows: 1) Depend on the third-party mechanisms. But the problem is that there may involve more mechanisms and there may be no mechanisms. For example, LSP Ping can be adopted to check the end-to-end connectivity or loop for the SR-BE path, but it cannot be used for path MTU negotiation. For the end-to-end path recording, LSP Tracert may have to be introduced. If these requirements and mechanisms are considered, it means SR does not reduce the complexity. Instead it just transfers more complexity to the other possible signalings. 2) Depend on one nodes to implement the possible functions. For example, for SR-TE path, it can depend on the PCE or the ingress node to collect all path information proposed by path recording or even path MTU negotiation. Even so, there is still some drawbacks for some scenarios if only depend on the ingress node. Moreover these methods cannot apply to SR-BE path. If the possible work is done through the ingress node, it will begin to change the essence of SR- BE and become the SR-TE. 3) Leave as it is. That is, these issues are not solved for SR path. As the concept of carrier-grade IP network has been widely accepted and these features mentioned has been deployed in the traditional MPLS network, these requirements cannot be removed easily. Though SR can utilize the MPLS forwarding plane, there exists several challenges for the end-to-end reachability when use IGP as the signaling which stops the communication between the upstream node and the downstream node. According to the [RFC3031], IGP cannot be seen as the traditional MPLS signaling like LDP and RSVP-TE. Thus It is difficult to make SR to replace the LDP or RSVP-TE in terms of the traditional MPLS signaling requirements. Segment Routing should be utilized as the extensions of the traditional MPLS concepts and will be useful for possible applications beyond the end-to-end reachability provided by the traditional LSP. 8. IANA Considerations This document makes no request of IANA. 9. Security Considerations TBD. Li Expires September 14, 2016 [Page 15] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 10. References 10.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, . 10.2. Informative References [I-D.ietf-spring-problem-statement] Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "SPRING Problem Statement and Requirements", draft-ietf-spring-problem-statement-07 (work in progress), March 2016. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-07 (work in progress), December 2015. [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, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, . Li Expires September 14, 2016 [Page 16] Internet-Draft Comparison between SR and LDP/RSVP-TE March 2016 [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, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, DOI 10.17487/RFC5283, July 2008, . [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . Author's Address Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li Expires September 14, 2016 [Page 17]