Internet DRAFT - draft-li-spring-compare-sr-ldp-rsvpte
draft-li-spring-compare-sr-ldp-rsvpte
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,
<http://www.rfc-editor.org/info/rfc2119>.
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,
<http://www.rfc-editor.org/info/rfc2702>.
[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>.
[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>.
[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,
<http://www.rfc-editor.org/info/rfc4461>.
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,
<http://www.rfc-editor.org/info/rfc4875>.
[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>.
[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,
<http://www.rfc-editor.org/info/rfc5283>.
[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,
<http://www.rfc-editor.org/info/rfc6388>.
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]
