draft-ietf-mpls-spring-entropy-label-11.txt   draft-ietf-mpls-spring-entropy-label-12.txt 
Network Working Group S. Kini Network Working Group S. Kini
Internet-Draft Internet-Draft
Intended status: Standards Track K. Kompella Intended status: Standards Track K. Kompella
Expires: November 24, 2018 Juniper Expires: January 17, 2019 Juniper
S. Sivabalan S. Sivabalan
Cisco Cisco
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
Google Google
J. Tantsura J. Tantsura
May 23, 2018 July 16, 2018
Entropy label for SPRING tunnels Entropy label for SPRING tunnels
draft-ietf-mpls-spring-entropy-label-11 draft-ietf-mpls-spring-entropy-label-12
Abstract Abstract
Segment Routing (SR) leverages the source routing paradigm. A node Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called steers a packet through an ordered list of instructions, called
segments. Segment Routing can be applied to the Multi Protocol Label segments. Segment Routing can be applied to the Multi Protocol Label
Switching (MPLS) data plane. Entropy label (EL) is a technique used Switching (MPLS) data plane. Entropy label (EL) is a technique used
in MPLS to improve load-balancing. This document examines and in MPLS to improve load-balancing. This document examines and
describes how ELs are to be applied to Segment Routing MPLS. describes how ELs are to be applied to Segment Routing MPLS.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2018. This Internet-Draft will expire on January 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4
3. Use-case requiring multipath load-balancing . . . . . . . . . 5 3. Use-case requiring multipath load-balancing . . . . . . . . . 5
4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 6 4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 6
5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7 5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 8
6. LSP stitching using the binding SID . . . . . . . . . . . . . 9 6. LSP stitching using the Binding-SID . . . . . . . . . . . . . 10
7. Insertion of entropy labels for SPRING path . . . . . . . . . 10 7. Insertion of entropy labels for SPRING path . . . . . . . . . 11
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. Example 1 where the ingress node has a sufficient MSD 11 7.1.1. Example 1 where the ingress node has a sufficient MSD 12
7.1.2. Example 2 where the ingress node has not a sufficient 7.1.2. Example 2 where the ingress node does not have a
MSD . . . . . . . . . . . . . . . . . . . . . . . . . 12 sufficient MSD . . . . . . . . . . . . . . . . . . . 13
7.2. Considerations for the placement of entropy labels . . . 13 7.2. Considerations for the placement of entropy labels . . . 14
7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 14 7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 15
7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 14 7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 16
7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 15 7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 16
7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 15 7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 17
7.2.2.3. Adjacency-SID representing a single IP link . . . 15 7.2.2.3. Adjacency-SID representing a single IP link . . . 17
7.2.2.4. Adjacency-SID representing a single link within a 7.2.2.4. Adjacency-SID representing a single link within
L2 bundle . . . . . . . . . . . . . . . . . . . . 16 an L2 bundle . . . . . . . . . . . . . . . . . . 17
7.2.2.5. Adjacency-SID representing a L2 bundle . . . . . 16 7.2.2.5. Adjacency-SID representing an L2 bundle . . . . . 17
7.2.3. Maximizing number of LSRs that will load-balance . . 16 7.2.3. Maximizing number of LSRs that will load-balance . . 18
7.2.4. Preference for a part of the path . . . . . . . . . . 16 7.2.4. Preference for a part of the path . . . . . . . . . . 18
7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 17 7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 18
8. A simple example algorithm . . . . . . . . . . . . . . . . . 17 8. A simple example algorithm . . . . . . . . . . . . . . . . . 18
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 19
10. Options considered . . . . . . . . . . . . . . . . . . . . . 18 10. Options considered . . . . . . . . . . . . . . . . . . . . . 20
10.1. Single EL at the bottom of the stack . . . . . . . . . . 18 10.1. Single EL at the bottom of the stack . . . . . . . . . . 20
10.2. An EL per segment in the stack . . . . . . . . . . . . . 19 10.2. An EL per segment in the stack . . . . . . . . . . . . . 20
10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 19 10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 21
10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 20 10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 21
10.5. ELs at readable label stack depths . . . . . . . . . . . 20 10.5. ELs at readable label stack depths . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14. Security Considerations . . . . . . . . . . . . . . . . . . . 22 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 22 15.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Segment Routing [I-D.ietf-spring-segment-routing] is based on source Segment Routing [I-D.ietf-spring-segment-routing] is based on source
routed tunnels to steer a packet along a particular path. This path routed tunnels to steer a packet along a particular path. This path
is encoded as an ordered list of segments. When applied to the MPLS is encoded as an ordered list of segments. When applied to the MPLS
dataplane [I-D.ietf-spring-segment-routing-mpls], each segment is an dataplane [I-D.ietf-spring-segment-routing-mpls], each segment is an
LSP with an associated MPLS label value. Hence, label stacking is LSP (Label Switched Path) with an associated MPLS label value.
used to represent the ordered list of segments and the label stack Hence, label stacking is used to represent the ordered list of
associated with an SR tunnel can be seen as nested LSPs (LSP segments and the label stack associated with an SR tunnel can be seen
hierarchy) in the MPLS architecture. as nested LSPs (LSP hierarchy) in the MPLS architecture.
Using label stacking to encode the list of segment has implications Using label stacking to encode the list of segments has implications
on the label stack depth. on the label stack depth.
Traffic load-balancing over ECMP (Equal Cost MultiPath) or LAGs (Link Traffic load-balancing over ECMP (Equal Cost Multi Path) or LAGs
Aggregation Groups) is usually based on a hashing function. The (Link Aggregation Groups) is usually based on a hashing function.
local node who performs the load-balancing is required to read some The local node which performs the load-balancing is required to read
header fields in the incoming packets and then computes a hash based some header fields in the incoming packets and then computes a hash
on these fields. The result of the hash is finally mapped to a list based on those fields. The result of the hash is finally mapped to a
of outgoing nexthops. The hashing technique is required to perfom a list of outgoing nexthops. The hashing technique is required to
per-flow load-balancing and thus prevent packet disordering. For IP perform a per-flow load-balancing and thus prevents packet
traffic, the usual fields that are looked up are the source address, misordering. For IP traffic, the usual fields that are hashed are
the destination address, the protocol type, and, if the upper layer the source address, the destination address, the protocol type, and,
is TCP or UDP, the source port and destination port can be added as if provided by the upper layer, the source port and destination port.
well in the hash.
The MPLS architecture brings some challenges on the load-balancing as The MPLS architecture brings some challenges when an LSR tries to
an LSR (Label Switch Router) should be able to look at header fields look up at header fields. An LSR (Label Switching Router) needs be
that are beyond the MPLS label stack. An LSR must perform a deeper able to look up at header fields that are beyond the MPLS label stack
inspection compared to an ingress router which could be challenging while the MPLS header does not provide any information about the
for some hardware. Entropy label (EL) [RFC6790] is a technique used upper layer protocol. An LSR must perform a deeper inspection
in the MPLS data plane to provide entropy for load-balancing. The compared to an ingress router which could be challenging for some
idea behind entropy label is that the ingress router computes a hash hardware. Entropy label (EL) [RFC6790] is a technique used in the
based on several fields from a given packet and place the result in MPLS data plane to provide entropy for load-balancing. The idea
behind the entropy label is that the ingress router computes a hash
based on several fields from a given packet and places the result in
an additional label, named "entropy label". Then, this entropy label an additional label, named "entropy label". Then, this entropy label
can be used as part of the hash keys used by an LSR. Using the can be used as part of the hash keys used by an LSR. Using the
entropy label in the hash keys reduces the need of a deep packet entropy label as part of the hash keys reduces the need for deep
inspection in the LSR while keeping a good level of entropy in the packet inspection in the LSR while keeping a good level of entropy in
load balancing. When entropy label is used, the keys used in the the load-balancing. When the entropy label is used, the keys used in
hashing functions are still a local configuration matter and an LSR the hashing functions are still a local configuration matter and an
may use solely the entropy label or a combination of multiple fields LSR may use solely the entropy label or a combination of multiple
from the incoming packet. fields from the incoming packet.
When using LSP hierarchies, there are implications on how [RFC6790] When using LSP hierarchies, there are implications on how [RFC6790]
should be applied. The current document addresses the case where a should be applied. The current document addresses the case where a
hierarchy is created at a single LSR as required by Segment Routing. hierarchy is created at a single LSR as required by Segment Routing.
A use-case requiring load-balancing with SR is given in Section 3. A A use-case requiring load-balancing with SR is given in Section 3. A
recommended solution is described in Section 7 keeping in recommended solution is described in Section 7 keeping in
consideration the limitations of implementations when applying consideration the limitations of implementations when applying
[RFC6790] to deeper label stacks. Options that were considered to [RFC6790] to deeper label stacks. Options that were considered to
arrive at the recommended solution are documented for historical arrive at the recommended solution are documented for historical
skipping to change at page 4, line 26 skipping to change at page 4, line 26
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Abbreviations and Terminology 2. Abbreviations and Terminology
Adj-SID - Adjacency Segment Identifier
ECMP - Equal Cost Multi Path
EL - Entropy Label EL - Entropy Label
ELI - Entropy Label Identifier ELI - Entropy Label Indicator
ELC - Entropy Label Capability ELC - Entropy Label Capability
ERLD - Entropy Readable Label Depth ERLD - Entropy Readable Label Depth
SR - Segment Routing FEC - Forwarding Equivalent Class
ECMP - Equal Cost Multi Path LAG - Link Aggregation Group
LSR - Label Switch Router LSP - Label Switched Path
LSR - Label Switching Router
MPLS - Multiprotocol Label Switching MPLS - Multiprotocol Label Switching
MSD - Maximum SID Depth MSD - Maximum SID Depth
SID - Segment Identifier Node-SID - Node Segment Identifier
OAM - Operation, Administration and Maintenance
RLD - Readable Label Depth RLD - Readable Label Depth
OAM - Operation, Administration and Maintenance SID - Segment Identifier
SPT - Shortest Path Tree
SR - Segment Routing
SRGB - Segment Routing Global Block
VPN - Virtual Private Network
3. Use-case requiring multipath load-balancing 3. Use-case requiring multipath load-balancing
+------+ +------+
| | | |
+-------| P3 |-----+ +-------| P3 |-----+
| +-----| |---+ | | +-----| |---+ |
L3| |L4 +------+ L1| |L2 +----+ L3| |L4 +------+ L1| |L2 +----+
| | | | +--| P4 |--+ | | | | +--| P4 |--+
+-----+ +-----+ +-----+ | +----+ | +-----+ +-----+ +-----+ +-----+ | +----+ | +-----+
skipping to change at page 5, line 25 skipping to change at page 5, line 36
| | | | | |--+ +--| | | | | | | |--+ +--| |
+-----+ +-----+ +-----+ | +----+ | +-----+ +-----+ +-----+ +-----+ | +----+ | +-----+
+--| P5 |--+ +--| P5 |--+
+----+ +----+
S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs, S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs,
L1,L2,L3,L4=Links L1,L2,L3,L4=Links
Figure 1: Traffic engineering use-case Figure 1: Traffic engineering use-case
Traffic-engineering is one of the applications of MPLS and is also a Traffic-engineering is one of the applications of MPLS and is also a
requirement for source routed tunnels with label stacks [RFC7855]. requirement for Segment Routing [RFC7855]. Consider the topology
Consider the topology shown in Figure 1. The LSR S requires data to shown in Figure 1. The LSR S requires data to be sent to LSR D along
be sent to LSR D along a traffic-engineered path that goes over the a traffic-engineered path that goes over the link L1. Good load-
link L1. Good load-balancing is also required across equal cost balancing is also required across equal cost paths (including
paths (including parallel links). To engineer traffic along a path parallel links). To steer traffic along a path that crosses link L1,
that takes link L1, the label stack that LSR S creates consists of a the label stack that LSR S creates consists of a label to the Node-
label to the node SID of LSR P3, stacked over the label for the SID of LSR P3, stacked over the label for the Adj-SID (Adjacency
adjacency SID of link L1 and that in turn is stacked over the label Segment Identifier) of link L1 and that in turn is stacked over the
to the node SID of LSR D. For simplicity lets assume that all LSRs label to the Node-SID of LSR D. For simplicity lets assume that all
use the same label space (SRGB) for source routed label stacks. Let LSRs use the same label space for Segment Routing (as a reminder, it
L_N-Px denote the label to be used to reach the node SID of LSR Px. is called the SRGB, Segment Routing Global Block). Let L_N-Px denote
Let L_A-Ln denote the label used for the adjacency SID for link Ln. the label to be used to reach the Node-SID of LSR Px. Let L_A-Ln
The LSR S must use the label stack <L_N-P3, L_A-L1, L_N-D> for denote the label used for the Adj-SID for link Ln. In our example,
traffic-engineering. However to achieve good load-balancing over the the LSR S must use the label stack <L_N-P3, L_A-L1, L_N-D>. However,
equal cost paths P2-P4-D, P2-P5-D and the parallel links L3, L4, a to achieve a good load-balancing over the equal cost paths P2-P4-D,
mechanism such as Entropy labels [RFC6790] should be adapted for P2-P5-D and the parallel links L3 and L4, a mechanism such as entropy
source routed label stacks. Indeed, the SPRING architecture with the labels [RFC6790] should be adapted for Segment Routing. Indeed, the
MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) uses nested SPRING architecture with the MPLS dataplane
MPLS LSPs composing the source routed label stacks. ([I-D.ietf-spring-segment-routing-mpls]) uses nested MPLS LSPs
composing the source routed label stack.
An MPLS node may have limitations in the number of labels it can An MPLS node may have limitations in the number of labels it can
push. It may also have a limitation in the number of labels it can push. It may also have a limitation in the number of labels it can
inspect when looking for hash keys during load-balancing. While inspect when looking for hash keys during load-balancing. While the
entropy label is normally inserted at the bottom of the transport entropy label is normally inserted at the bottom of the transport
tunnel, this may prevent an LSR to take into account the EL in its tunnel, this may prevent an LSR from taking into account the EL in
load-balancing function if the EL is too deep in the stack. In a its load-balancing function if the EL is too deep in the stack. In a
segment routing environment, it is important to define the Segment Routing environment, it is important to define the
considerations that needs to be taken into account when inserting EL. considerations that needs to be taken into account when inserting an
Multiple ways to apply entropy labels were considered and are EL. Multiple ways to apply entropy labels were considered and are
documented in Section 10 along with their trade-offs. A recommended documented in Section 10 along with their trade-offs. A recommended
solution is described in Section 7. solution is described in Section 7.
4. Entropy Readable Label Depth 4. Entropy Readable Label Depth
The Entropy Readable Label Depth (ERLD) is defined as the number of The Entropy Readable Label Depth (ERLD) is defined as the number of
labels a router can both: labels a router can both:
a. Read in an MPLS packet received on its incoming interface(s) a. Read in an MPLS packet received on its incoming interface(s)
(starting from the top of the stack). (starting from the top of the stack).
b. Use in its load-balancing function. b. Use in its load-balancing function.
The ERLD means that the router will perform load-balancing using the The ERLD means that the router will perform load-balancing using the
EL label if the EL is placed within the ERLD first labels. EL label if the EL is placed within the first ERLD labels.
A router capable of reading N labels but not using an EL located A router capable of reading N labels but not using an EL located
within those N labels MUST consider its ERLD to be 0. In a within those N labels MUST consider its ERLD to be 0.
distributed switching architecture, each linecard may have a
In a distributed switching architecture, each linecard may have a
different capability in terms of ERLD. For simplicity, an different capability in terms of ERLD. For simplicity, an
implementation MAY use the minimum ERLD between each linecard as the implementation MAY use the minimum ERLD of all linecards as the ERLD
ERLD value for the system. value for the system.
There may also be a case where a router has a fast switching path
(handled by an ASIC or network processor) and a slow switching path
(handled by a CPU) with a different ERLD for each switching path.
Again, for simplicity's sake, an implementation MAY use the minimum
ERLD as the ERLD value for the system.
The drawback of using a single ERLD for a system lower than the
capability of one or more specific component is that it may increase
the number of ELI/ELs inserted. This leads to an increase of the
label stack size and may have an impact on the capability of the
ingress node to push this label stack.
Examples: Examples:
| Payload | | Payload |
+----------+ +----------+
| Payload | | EL | P7 | Payload | | EL | P7
+----------+ +----------+ +----------+ +----------+
| Payload | | EL | | ELI | | Payload | | EL | | ELI |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| Payload | | EL | | ELI | | Label 50 | | Payload | | EL | | ELI | | Label 50 |
skipping to change at page 7, line 5 skipping to change at page 7, line 29
| EL | | ELI | | Label 30 | | Label 30 | | Label 30 | | EL | | ELI | | Label 30 | | Label 30 | | Label 30 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| ELI | | Label 20 | | Label 20 | | Label 20 | | Label 20 | | ELI | | Label 20 | | Label 20 | | Label 20 | | Label 20 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| Label 16 | | Label 16 | | Label 16 | | Label 16 | | Label 16 | P1 | Label 16 | | Label 16 | | Label 16 | | Label 16 | | Label 16 | P1
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 1 Packet 2 Packet 3 Packet 4 Packet 5
Figure 2: Label stacks with ELI/EL Figure 2: Label stacks with ELI/EL
In the figure 2, we consider the displayed packets received on a In Figure 2, we consider the displayed packets received on a router
router interface. We consider also a single ERLD value for the interface. We consider also a single ERLD value for the router.
router.
o If the router has an ERLD of 3, it will be able to load-balance o If the router has an ERLD of 3, it will be able to load-balance
Packet 1 displayed in Figure 2 using the EL as part of the load- Packet 1 displayed in Figure 2 using the EL as part of the load-
balancing keys. The ERLD value of 3 means that the router can balancing keys. The ERLD value of 3 means that the router can
read and take into account the entropy label for load-balancing if read and take into account the entropy label for load-balancing if
it is placed between position 1 (top) and position 3. it is placed between position 1 (top of the MPLS label stack) and
position 3.
o If the router has an ERLD of 5, it will be able to load-balance o If the router has an ERLD of 5, it will be able to load-balance
Packets 1 to 3 in Figure 2 using the EL as part of the load- Packets 1 to 3 in Figure 2 using the EL as part of the load-
balancing keys. Packets 4 and 5 have the EL placed at a position balancing keys. Packets 4 and 5 have the EL placed at a position
greater than 5, so the router is not able to read it and use as greater than 5, so the router is not able to read it and use as
part of the load-balancing keys. part of the load-balancing keys.
o If the router has an ERLD of 10, it will be able to load-balance o If the router has an ERLD of 10, it will be able to load-balance
all the packets displayed in Figure 2 using the EL as part of the all the packets displayed in Figure 2 using the EL as part of the
load-balancing keys. load-balancing keys.
To allow an efficient load-balancing based on entropy labels, a To allow an efficient load-balancing based on entropy labels, a
router running SPRING SHOULD advertise its ERLD (or ERLDs), so all router running SPRING SHOULD advertise its ERLD (or ERLDs), so all
the other SPRING routers in the network are aware of its capability. the other SPRING routers in the network are aware of its capability.
How this advertisement is done is outside the scope of this document.
How this advertisement is done is outside the scope of this document
(see Section 7.2.1 for potential approaches).
To advertise an ERLD value, a SPRING router: To advertise an ERLD value, a SPRING router:
o MUST be entropy label capable and, as a consequence, MUST apply o MUST be entropy label capable and, as a consequence, MUST apply
the dataplane procedures defined in [RFC6790]. the dataplane procedures defined in [RFC6790].
o MUST be able to read an ELI/EL which is located within its ERLD o MUST be able to read an ELI/EL which is located within its ERLD
value. value.
o MUST take into account this EL in its load-balancing function. o MUST take into account an EL within the first ERLD labels in its
load-balancing function.
5. Maximum SID Depth 5. Maximum SID Depth
The Maximum SID Depth defines the maximum number of labels that a The Maximum SID Depth defines the maximum number of labels that a
particular node can impose on a packet. This includes any kind of particular node can impose on a packet. This can include any kind of
labels (service, entropy, transport...). In an MPLS network, the MSD labels (service, entropy, transport...). In an MPLS network, the MSD
is a limit of the Ingress LSR (I-LSR) or any stitching node that is a limit of the head-end of an SR tunnel or a Binding-SID anchor
would perform an imposition of additional labels on an existing label node that performs imposition of additional labels on an existing
stack. label stack.
Depending of the number of MPLS operations (POP, SWAP...) to be Depending on the number of MPLS operations (POP, SWAP...) to be
performed before the PUSH, the MSD may vary due to the hardware or performed before the PUSH, the MSD can vary due to hardware or
software limitations. As for the ERLD, there may also be different software limitations. As for the ERLD, different MSD limits can
MSD limits based on the linecard type used in a distributed switching exist within a single node based on the linecard types used in a
system. distributed switching system. Thus, the MSD is a per link and/or per
node property.
When an external controller is used to program a label stack on a An external controller can be used to program a label stack on a
particular node, this node MAY advertise its MSD value or a subset of particular node. This node SHOULD advertise its MSD to the
its MSD value to the controller. How this advertisement is done is controller in order to let the controller know the maximum label
outside the scope of this document. As the controller does not have stack depth of the path computed that is supported on the head-end.
the knowledge of the entire label stack to be pushed by the node, the How this advertisement is done is outside the scope of this document
node may advertise an MSD value which is lower than its actual limit. ([I-D.ietf-isis-segment-routing-msd],
This gives the ability for the controller to program a label stack up [I-D.ietf-isis-segment-routing-msd] and
to the advertised MSD value while leaving room for the local node to [I-D.ietf-idr-bgp-ls-segment-routing-msd] provide examples of
add more labels (e.g., service, entropy, transport...) without advertisement of MSD). As the controller does not have the knowledge
reaching the hardware/software limit. of the entire label stack to be pushed by the node, in addition to
the MSD value, the node SHOULD advertise the type of the MSD. For
instance, the MSD value can represent the limit for pushing transport
labels only while in reality the node can push an additional service
label. As another example, the MSD value can represent the full
limit of the node including all label types (transport, service,
entropy...). This gives the ability for the controller to program a
label stack while leaving room for the local node to add more labels
(e.g., service, entropy,...) without reaching the hardware/software
limit. If the node does not provide the meaning of the MSD value,
the controller could program an LSP using a number of labels equal to
the full limit of the node. When receiving this label stack from the
controller, the ingress node may not be able to add any service
(L2VPN, L3VPN, EVPN...) label on top of this label stack. The
consequence could be for the ingress node to drop service packets
that should have been forwarded over the LSP.
P7 ---- P8 ---- P9 P7 ---- P8 ---- P9
/ \ / \
PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2
| \ | | \ |
----> P10 \ | ----> P10 \ |
IP Pkt | \ | IP Pkt | \ |
P11 --- P12 --- P13 P11 --- P12 --- P13
100 10000 100 10000
Figure 3 Figure 3
In the figure 3, an IP packet comes in the MPLS network at PE1. All In Figure 3, an IP packet comes into the MPLS network at PE1. All
metrics are considered equal to 1 except P12-P13 which is 10000 and metrics are considered equal to 1 except P12-P13 which is 10000 and
P11-P12 which is 100. PE1 wants to steer the traffic using a SPRING P11-P12 which is 100. PE1 wants to steer the traffic using a SPRING
path to PE2 along path to PE2 along
PE1->P1->P7->P8->P9->P4->P5->P10->P11->P12->P13->PE2. By using PE1->P1->P7->P8->P9->P4->P5->P10->P11->P12->P13->PE2. By using Adj-
adjacency SIDs only, PE1 (acting as an I-LSR) will be required to SIDs only, PE1 (acting as an I-LSR) will be required to push 10
push 10 labels on the IP packet received and thus requires an MSD of labels on the IP packet received and thus requires an MSD of 10. If
10. If the IP packet should be carried over an MPLS service like a the IP packet should be carried over an MPLS service like a regular
regular layer 3 VPN, an additional service label should be imposed, layer 3 VPN, an additional service label should be imposed, requiring
requiring an MSD of 11 for PE1. In addition, if PE1 wants to insert an MSD of 11 for PE1. In addition, if PE1 wants to insert an ELI/EL
an ELI/EL for load-balancing purpose, PE1 will need to push 13 labels for load-balancing purpose, PE1 will need to push 13 labels on the IP
on the IP packet requiring an MSD of 13. packet requiring an MSD of 13.
In the SPRING architecture, Node SIDs or Binding SIDs can be used to In the SPRING architecture, Node-SIDs or Binding-SIDs can be used to
reduce the label stack size. As an example, to steer the traffic on reduce the label stack size. As an example, to steer the traffic on
the same path as before, PE1 may be able to use the following label the same path as before, PE1 could use the following label stack:
stack: <Node_P9, Node_P5, Binding_P5, Node_PE2>. In this example we <Node_P9, Node_P5, Binding_P5, Node_PE2>. In this example we
consider a combination of Node SIDs and a Binding SID advertised by consider a combination of Node-SIDs and a Binding-SID advertised by
P5 that will stitch the traffic along the path P10->P11->P12->P13. P5 that will stitch the traffic along the path P10->P11->P12->P13.
The instruction associated with the binding SID at P5 is thus to swap The instruction associated with the Binding-SID at P5 is thus to swap
Binding_P5 to Adj_P12-P13 and then push <Adj_P11-P12, Node_P11>. P5 Binding_P5 to Adj_P12-P13 and then push <Adj_P11-P12, Node_P11>. P5
acts as a stitching node that pushes additional labels on an existing acts as a stitching node that pushes additional labels on an existing
label stack, P5's MSD needs also to be taken into account and may label stack, P5's MSD needs also to be taken into account and may
limit the number of labels that could be imposed. limit the number of labels that can be imposed.
6. LSP stitching using the binding SID 6. LSP stitching using the Binding-SID
The binding SID allows binding a segment identifier to an existing The Binding-SID allows binding a segment identifier to an existing
LSP. As examples, the binding SID can represent an RSVP-TE tunnel, LSP. As examples, the Binding-SID can represent an RSVP-TE tunnel,
an LDP path (through the mapping server advertisement), or a SPRING an LDP path (through the mapping server advertisement), or a SPRING
path. Each LSP associated with a binding SID has its own entropy path. Each tail-end router of an MPLS LSP associated with a Binding-
label capability. SID has its own entropy label capability. The entropy label
capability of the associated LSP is advertised in the control plane
protocol used to signal the LSP.
In the figure 3, we consider that: In Figure 4, we consider that:
o P6, PE2, P10, P11, P12, P13 are pure LDP routers. o P6, PE2, P10, P11, P12, P13 are pure LDP routers.
o PE1, P1, P2, P3, P4, P7, P8, P9 are pure SPRING routers. o PE1, P1, P2, P3, P4, P7, P8, P9 are pure SPRING routers.
o P5 is running SPRING and LDP. o P5 is running SPRING and LDP.
o P5 acts as a mapping server and advertises Prefix SIDs for the LDP o P5 acts as a mapping server and advertises Prefix SIDs for the LDP
FECs: an index value of 20 is used for PE2. FECs: an index value of 20 is used for PE2.
skipping to change at page 9, line 41 skipping to change at page 10, line 41
PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2 PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2
--> +----+ +----+ +----+ +----+ --> +----+ +----+ +----+ +----+
IP Pkt | IP | | IP | | IP | | IP | IP Pkt | IP | | IP | | IP | | IP |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
|1020| |1020| | 20 | |1020| |1020| | 20 |
+----+ +----+ +----+ +----+ +----+ +----+
SPRING LDP SPRING LDP
In term of packet forwarding, by learning the mapping-server In terms of packet forwarding, by learning the mapping-server
advertisement from P5, PE1 imposes a label 1020 to an IP packet advertisement from P5, PE1 imposes a label 1020 to an IP packet
destinated to PE2. SPRING routers along the shortest path to PE2 destined to PE2. SPRING routers along the shortest path to PE2 will
will switch the traffic until it reaches P5 which will perform the switch the traffic until it reaches P5. P5 will perform the LSP
LSP stitching. P5 will swap the SPRING label 1020 to the LDP label stitching by swapping the SPRING label 1020 to the LDP label 20
20 advertised by the nexthop P6. P6 will then forward the packet advertised by the nexthop P6. P6 will finally forward the packet
using the LDP label towards PE2. using the LDP label towards PE2.
PE1 cannot push an ELI/EL for the binding SID without knowing that PE1 cannot push an ELI/EL for the Binding-SID without knowing that
the tail-end of the LSP associated with the binding (PE2) is entropy the tail-end of the LSP associated with the binding (PE2) is entropy
label capable. label capable.
To accomodate the mix of signaling protocols involved during the To accommodate the mix of signaling protocols involved during the
stitching, the entropy label capability SHOULD be propagated between stitching, the entropy label capability SHOULD be propagated between
the signaling domains. Each binding SID SHOULD have its own entropy the signaling domains. Each Binding-SID SHOULD have its own entropy
label capability that MUST be inherited from the entropy label label capability that MUST be inherited from the entropy label
capability of the associated LSP. If the router advertising the capability of the associated LSP. If the router advertising the
binding SID does not know the ELC state of the target FEC, it MUST Binding-SID does not know the ELC state of the target FEC, it MUST
NOT set the ELC for the binding SID. An ingress node MUST NOT push NOT set the ELC for the Binding-SID. An ingress node MUST NOT push
an ELI/EL associated with a binding SID unless this binding SID has an ELI/EL associated with a Binding-SID unless this Binding-SID has
the entropy label capability. How the entropy label capability is the entropy label capability. How the entropy label capability is
advertised for a binding SID is outside the scope of this document. advertised for a Binding-SID is outside the scope of this document
(see Section 7.2.1 for potential approaches).
In our example, if PE2 is LDP entropy label capable, it will add the In our example, if PE2 is LDP entropy label capable, it will add the
entropy label capability in its LDP advertisement. When P5 receives entropy label capability in its LDP advertisement. When P5 receives
the FEC/label binding for PE2, it learns about the ELC and can set the FEC/label binding for PE2, it learns about the ELC and can set
the ELC in the mapping server advertisement. Thus PE1 learns about the ELC in the mapping server advertisement. Thus PE1 learns about
the ELC of PE2 and may push an ELI/EL associated with the binding the ELC of PE2 and may push an ELI/EL associated with the Binding-
SID. SID.
The proposed solution only works if the SPRING router advertising the The proposed solution only works if the SPRING router advertising the
binding SID is also performing the dataplane LSP stitching. In our Binding-SID is also performing the dataplane LSP stitching. In our
example, if the mapping server function is hosted on P8 instead of example, if the mapping server function is hosted on P8 instead of
P5, P8 does not know about the ELC state of PE2's LDP FEC. As a P5, P8 does not know about the ELC state of PE2's LDP FEC. As a
consequence, it does not set the ELC for the associated binding SID. consequence, it does not set the ELC for the associated Binding-SID.
7. Insertion of entropy labels for SPRING path 7. Insertion of entropy labels for SPRING path
7.1. Overview 7.1. Overview
The solution described in this section follows the dataplane The solution described in this section follows the dataplane
processing defined in [RFC6790]. Within a SPRING path, a node may be processing defined in [RFC6790]. Within a SPRING path, a node may be
ingress, egress, transit (regarding the entropy label processing ingress, egress, transit (regarding the entropy label processing
described in [RFC6790]), or it can be any combination of those. For described in [RFC6790]), or it can be any combination of those. For
example: example:
o The ingress node of a SPRING domain may be an ingress node from an o The ingress node of a SPRING domain can be an ingress node from an
entropy label perspective. entropy label perspective.
o Any LSR terminating a segment of the SPRING path is an egress node o Any LSR terminating a segment of the SPRING path is an egress node
(because it terminates the segment) but may also be a transit node (because it terminates the segment) but can also be a transit node
if the SPRING path is not terminated because there is a subsequent if the SPRING path is not terminated because there is a subsequent
SPRING MPLS label in the stack. SPRING MPLS label in the stack.
o Any LSR processing a binding SID may be a transit node and an o Any LSR processing a Binding-SID may be a transit node and an
ingress node (because it may push additional labels when ingress node (because it may push additional labels when
processing the binding SID). processing the Binding-SID).
As described earlier, an LSR may have a limitation, ERLD, on the As described earlier, an LSR may have a limitation (the ERLD) on the
depth of the label stack that it can read and process in order to do depth of the label stack that it can read and process in order to do
multipath load-balancing based on entropy labels. multipath load-balancing based on entropy labels.
If an EL does not occur within the ERLD of an LSR in the label stack If an EL does not occur within the ERLD of an LSR in the label stack
of an MPLS packet that it receives, then it would lead to poor load- of an MPLS packet that it receives, then it would lead to poor load-
balancing at that LSR. Hence an ELI/EL pair must be within the ERLD balancing at that LSR. Hence an ELI/EL pair must be within the ERLD
of the LSR in order for the LSR to use the EL during load-balancing. of the LSR in order for the LSR to use the EL during load-balancing.
Adding a single ELI/EL pair for the entire SPRING path may lead also Adding a single ELI/EL pair for the entire SPRING path can also lead
to poor load-balancing as well because the EL/ELI may not occur to poor load-balancing as well because the ELI/EL may not occur
within the ERLD of some LSR on the path (if too deep) or may not be within the ERLD of some LSR on the path (if too deep) or may not be
present in the stack when it reaches some LSRs if it is too shallow. present in the stack when it reaches some LSRs (if it is too
shallow).
In order for the EL to occur within the ERLD of LSRs along the path In order for the EL to occur within the ERLD of LSRs along the path
corresponding to a SPRING label stack, multiple <ELI, EL> pairs MAY corresponding to a SPRING label stack, multiple <ELI, EL> pairs MAY
be inserted in this label stack. be inserted in this label stack.
The insertion of the ELI/EL SHOULD occur only with a SPRING label The insertion of an ELI/EL MUST occur only with a SPRING label
advertised by an LSR that advertised an ERLD (the LSR is entropy advertised by an LSR that advertised an ERLD (the LSR is entropy
label capable) or with a SPRING label associated with a binding SID label capable) or with a SPRING label associated with a Binding-SID
that has the ELC set. that has the ELC set.
The ELs among multiple <ELI, EL> pairs inserted in the stack MAY be The ELs among multiple <ELI, EL> pairs inserted in the stack MAY be
the same or different. The LSR that inserts <ELI, EL> pairs MAY have the same or different. The LSR that inserts <ELI, EL> pairs can have
limitations on the number of such pairs that it can insert and also limitations on the number of such pairs that it can insert and also
the depth at which it can insert them. If, due to limitations, the the depth at which it can insert them. If, due to limitations, the
inserted ELs are at positions such that an LSR along the path inserted ELs are at positions such that an LSR along the path
receives an MPLS packet without an EL in the label stack within that receives an MPLS packet without an EL in the label stack within that
LSR's ERLD, then the load-balancing performed by that LSR would be LSR's ERLD, then the load-balancing performed by that LSR would be
poor. An implementation MAY consider multiple criteria when poor. An implementation MAY consider multiple criteria when
inserting <ELI, EL> pairs. inserting <ELI, EL> pairs.
7.1.1. Example 1 where the ingress node has a sufficient MSD 7.1.1. Example 1 where the ingress node has a sufficient MSD
ECMP LAG LAG ECMP LAG LAG
PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2
Figure 4 Figure 5
In the figure 4, PE1 wants to forward some MPLS VPN traffic over an In Figure 5, PE1 wants to forward some MPLS VPN traffic over an
explicit path to PE2 resulting in the following label stack to be explicit path to PE2 resulting in the following label stack to be
pushed onto the received IP header: <Adj_P1P2, Adj_set_P2P3, pushed onto the received IP header: <Adj_P1P2, Adj_set_P2P3,
Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_P6PE2, VPN_label>. PE1 is limited Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_P6PE2, VPN_label>. PE1 is limited
to push a maximum of 11 labels (MSD=11). P2, P3 and P6 have an ERLD to push a maximum of 11 labels (MSD=11). P2, P3 and P6 have an ERLD
of 3 while others have an ERLD of 10. of 3 while others have an ERLD of 10.
PE1 can only add two ELI/EL pairs in the label stack due to its MSD PE1 can only add two ELI/EL pairs in the label stack due to its MSD
limitation. It should insert them strategically to benefit load- limitation. It should insert them strategically to benefit load-
balancing along the longest part of the path. balancing along the longest part of the path.
PE1 may take into account multiple parameters when inserting ELs, as PE1 can take into account multiple parameters when inserting ELs, as
examples: examples:
o The ERLD value advertised by transit nodes. o The ERLD value advertised by transit nodes.
o The requirement of load-balancing for a particular label value. o The requirement of load-balancing for a particular label value.
o Any service provider preference: favor beginning of the path or o Any service provider preference: favor beginning of the path or
end of the path. end of the path.
In the figure 4, a good strategy may be to use the following stack In Figure 5, a good strategy may be to use the following stack
<Adj_P1P2, Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6, <Adj_P1P2, Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6,
Adj_P6PE2, VPN_label>. The original stack requests P2 to forward Adj_P6PE2, ELI2, EL2, VPN_label>. The original stack requests P2 to
based on a L3 adjacency set that will require load-balancing. forward based on a L3 adjacency set that will require load-balancing.
Therefore it is important to ensure that P2 can load-balance Therefore it is important to ensure that P2 can load-balance
correctly. As P2 has a limited ERLD of 3, ELI/EL must be inserted correctly. As P2 has a limited ERLD of 3, an ELI/EL must be inserted
just next to the label that P2 will use to forward. On the path to just after the label that P2 will use to forward. On the path to
PE2, P3 has also a limited ERLD, but P3 will forward based on a basic PE2, P3 has also a limited ERLD, but P3 will forward based on a
adjacency segment that may require no load-balancing. Therefore it regular adjacency segment that may not require load-balancing.
does not seem important to ensure that P3 can do load-balancing Therefore it does not seem important to ensure that P3 can do load-
despite of its limited ERLD. The next nodes along the forwarding balancing despite its limited ERLD. The next nodes along the
path have a high ERLD that does not cause any issue, except P6, forwarding path have a high ERLD that does not cause any issue,
moreover P6 is using some LAGs to PE2 and so is expected to load- except P6. Moreover, P6 is using some LAGs to PE2 and so is expected
balance. It becomes important to insert a new ELI/EL just next to P6 to load-balance. It becomes important to insert a new ELI/EL just
forwarding label. after the P6 forwarding label.
In the case above, the ingress node had enough label push capacity to In the case above, the ingress node had a sufficient MSD to ensure
ensure end-to-end load-balancing taking into the path attributes. end-to-end load-balancing taking into the path attributes. However,
There might be some cases, where the ingress node may not have the there might be cases where the ingress node may not have the
necessary label imposition capacity. necessary label imposition capacity.
7.1.2. Example 2 where the ingress node has not a sufficient MSD 7.1.2. Example 2 where the ingress node does not have a sufficient MSD
ECMP LAG ECMP ECMP ECMP LAG ECMP ECMP
PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- P7 --- P8 --- PE2 PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- P7 --- P8 --- PE2
Figure 5 Figure 6
In the figure 5, PE1 wants to forward MPLS VPN traffic over an In Figure 6, PE1 wants to forward MPLS VPN traffic over an explicit
explicit path to PE2 resulting in the following label stack to be path to PE2 resulting in the following label stack to be pushed onto
pushed onto the IP header: <Adj_P1P2, Adj_set_P2P3, Adj_P3P4, the IP header: <Adj_P1P2, Adj_set_P2P3, Adj_P3P4, Adj_P4P5, Adj_P5P6,
Adj_P4P5, Adj_P5P6, Adj_set_P6P7, Adj_P7P8; Adj_set_P8PE2, Adj_set_P6P7, Adj_P7P8; Adj_set_P8PE2, VPN_label>. PE1 is limited to
VPN_label>. PE1 is limited to push a maximum of 11 labels, P2, P3 push a maximum of 11 labels. P2, P3 and P6 have an ERLD of 3 while
and P6 have an ERLD of 3 while others have an ERLD of 15. others have an ERLD of 15.
Using a similar strategy as the previous case may lead to a dilemma, Using a similar strategy as the previous case may lead to a dilemma,
as PE1 can only push a single ELI/EL while we may need a minimum of as PE1 can only push a single ELI/EL while we may need a minimum of
three to load-balance the end-to-end path. An optimized stack that three to load-balance the end-to-end path. An optimized stack that
would enable end-to-end load-balancing may be: <Adj_P1P2, would enable end-to-end load-balancing may be: <Adj_P1P2,
Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_set_P6P7, Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_set_P6P7,
ELI2, EL2, Adj_P7P8; Adj_set_P8PE2, ELI3, EL3, VPN_label>. ELI2, EL2, Adj_P7P8, Adj_set_P8PE2, ELI3, EL3, VPN_label>.
A decision needs to be taken to favor some part of the path for load- A decision needs to be taken to favor some part of the path for load-
balancing considering that load-balancing may not work on the other balancing considering that load-balancing may not work on the other
part. A service provider may decide to place the ELI/EL after the P6 parts. A service provider may decide to place the ELI/EL after the
forwarding label as it will allow P4 and P6 to load-balance. Placing P6 forwarding label as it will allow P4 and P6 to load-balance.
the ELI/EL at bottom of the stack is also a possibility enabling Placing the ELI/EL at bottom of the stack is also a possibility
load-balancing for P4 and P8. enabling load-balancing for P4 and P8.
7.2. Considerations for the placement of entropy labels 7.2. Considerations for the placement of entropy labels
The sample cases described in the previous section showed that The sample cases described in the previous section showed that ELI/EL
placing the ELI/EL when the maximum number of labels to be pushed is placement when the maximum number of labels to be pushed is limited
limited is not an easy decision and multiple criteria may be taken is not an easy decision and multiple criteria may be taken into
into account. account.
This section describes some considerations that could be taken into This section describes some considerations that an implementation MAY
account when placing ELI/ELs. This list of criteria is not take into account when placing ELI/ELs. This list of criteria is not
considered as exhaustive and an implementation MAY take into account considered exhaustive and an implementation MAY take into account
additional criteria or tie-breakers that are not documented here. additional criteria or tie-breakers that are not documented here. As
the insertion of ELI/ELs is performed by the ingress node, having
ingress nodes that do not use the same criteria does not cause an
interoperability issue. However, from a network design and operation
perspective, it is better to have all ingress routers using the same
criteria.
An implementation SHOULD try to maximize the load-balancing where An implementation SHOULD try to maximize the possibility of load-
multiple ECMP paths are available and minimize the number of EL/ELIs balancing along the path by inserting an ELI/EL where multiple equal
that need to be inserted. In case of a trade-off, an implementation cost paths are available and minimize the number of ELI/ELs that need
MAY provide flexibility to the operator to select the criteria to be to be inserted. In case of a trade-off, an implementation SHOULD
considered when placing EL/ELIs or the sub-objective for which to provide flexibility to the operator to select the criteria to be
optimize. considered when placing ELI/ELs or specify a sub-objective for
optimization.
2 2 2 2
PE1 -- P1 -- P2 --P3 --- P4 --- P5 -- ... -- P8 -- P9 -- PE2 PE1 -- P1 -- P2 --P3 --- P4 --- P5 -- ... -- P8 -- P9 -- PE2
| | | |
P3'--- P4'--- P5' P3'--- P4'--- P5'
Figure 6 Figure 7
The figure above will be used as reference in the following Figure 7 will be used as reference in the following subsections. All
subsections. All metrics are equal to 1, except P3-P4 and P4-P5 metrics are equal to 1, except P3-P4 and P4-P5 which have a metric 2.
which have a metric 2. We consider the MSD of nodes to be the full limit of label imposition
(including service labels, entropy labels and transport labels).
7.2.1. ERLD value 7.2.1. ERLD value
As mentioned in Section 7.1, the ERLD value is an important parameter As mentioned in Section 7.1, the ERLD value is an important parameter
to consider when inserting ELI/EL. If an ELI/EL does not fall within to consider when inserting an ELI/EL. If an ELI/EL does not fall
the ERLD of a node on the path, the node will not be able to load- within the ERLD of a node on the path, the node will not be able to
balance the traffic efficiently. load-balance the traffic efficiently.
The ERLD value can be advertised via protocols and those extensions The ERLD value can be advertised via protocols and those extensions
are described in separate documents [I-D.ietf-isis-mpls-elc] and are described in separate documents (for instance,
[I-D.ietf-ospf-mpls-elc]. [I-D.ietf-isis-mpls-elc] and [I-D.ietf-ospf-mpls-elc]).
Let's consider a path from PE1 to PE2 using the following stack Let's consider a path from PE1 to PE2 using the following stack
pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, Service_label>. pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, Service_label>.
Using the ERLD as an input parameter may help to minimize the number Using the ERLD as an input parameter can help to minimize the number
of required ELI/EL pairs to be inserted. An ERLD value must be of required ELI/EL pairs to be inserted. An ERLD value must be
retrieved for each SPRING label in the label stack. retrieved for each SPRING label in the label stack.
For a label bound to an adjacency segment, the ERLD is the ERLD of For a label bound to an adjacency segment, the ERLD is the ERLD of
the node that advertised the adjacency segment. In the example the node that has advertised the adjacency segment. In the example
above, the ERLD associated with Adj_P1P2 would be the ERLD of router above, the ERLD associated with Adj_P1P2 would be the ERLD of router
P1 as P1 will perform the forwarding based on the Adj_P1P2 label. P1 as P1 will perform the forwarding based on the Adj_P1P2 label.
For a label bound to a node segment, multiple strategies MAY be For a label bound to a node segment, multiple strategies MAY be
implemented. An implementation may try to evaluate the minimum ERLD implemented. An implementation MAY try to evaluate the minimum ERLD
value along the node segment path. If an implementation cannot find value along the node segment path. If an implementation cannot find
the minimum ERLD along the path of the segment, it can use the ERLD the minimum ERLD along the path of the segment or does not support
of the starting node instead. In the example above, if the the computation of the minimum ERLD, it SHOULD instead use the ERLD
of the tail-end node. Using the ERLD of the tail-end of the node
segment mimics the behavior of [RFC6790] where the ingress takes only
care of the egress of the LSP. In the example above, if the
implementation supports computation of minimum ERLD along the path, implementation supports computation of minimum ERLD along the path,
the ERLD associated with label Node_P9 would be the minimum ERLD the ERLD associated with label Node_P9 would be the minimum ERLD
between nodes {P2,P3,P4 ..., P8}. If an implementation does not between nodes {P2,P3,P4 ..., P8}. If the implementation does not
support the computation of minimum ERLD, it should consider the ERLD support the computation of minimum ERLD, it will consider the ERLD of
of P2 (starting node that will forward based on the Node_P9 label). P9 (tail-end node of Node_P9 SID). While providing the more optimal
ELI/EL placement, evaluating the minimum ERLD increases the
complexity of ELI/EL insertion. As the path to the Node-SID may
change over time, a recomputation of the minimum ERLD is required for
each topology change. This recomputation may require the positions
of the ELI/ELs to change.
For a label bound to a binding segment, if the binding segment For a label bound to a binding segment, if the binding segment
describes a path, an implementation may also try to evaluate the describes a path, an implementation MAY also try to evaluate the
minimum ERLD along this path. If the implementation cannot find the minimum ERLD along this path. If the implementation cannot find the
minimum ERLD along the path of the segment, it can use the ERLD of minimum ERLD along the path of the segment or does not support this
the starting node instead. evaluation, it SHOULD instead use the ERLD of the node advertising
the Binding-SID. As for the node segment, evaluating the minimum
ERLD adds complexity in the ELI/EL insertion process.
7.2.2. Segment type 7.2.2. Segment type
Depending of the type of segment a particular label is bound to, an Depending on the type of segment a particular label is bound to, an
implementation may deduce that this particular label will be subject implementation can deduce that this particular label will be subject
to load-balancing on the path. to load-balancing on the path.
7.2.2.1. Node-SID 7.2.2.1. Node-SID
An MPLS label bound to a Node-SID represents a path that may cross An MPLS label bound to a Node-SID represents a path that may cross
multiple hops. Load-balancing may be needed on the node starting multiple hops. Load-balancing may be needed on the node starting
this path but also on any node along the path. this path but also on any node along the path.
In the figure 6, let's consider a path from PE1 to PE2 using the In Figure 7, let's consider a path from PE1 to PE2 using the
following stack pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, following stack pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2,
Service_label>. Service_label>.
If, for example, PE1 is limited to push 6 labels, it can add a single If, for example, PE1 is limited to push 6 labels, it can add a single
ELI/EL within the label stack. An operator may want to favor a ELI/EL within the label stack. An operator may want to favor a
placement that would allow load-balancing along the Node-SID path. placement that would allow load-balancing along the Node-SID path.
In the figure above, P3 which is along the Node-SID path requires In Figure 7, P3 which is along the Node-SID path requires load-
load-balancing on two equal-cost paths. balancing between two equal-cost paths.
An implementation may try to evaluate if load-balancing is really An implementation MAY try to evaluate if load-balancing is really
required within a node segment path. This could be done by running required within a node segment path. This could be done by running
an additional SPT computation and analysis of the node segment path an additional SPT (Shortest Path Tree) computation and analysing of
to prevent a node segment that does not really require load-balancing the node segment path to prevent a node segment that does not really
from being preferred when placing EL/ELIs. Such inspection may be require load-balancing from being preferred when placing ELI/ELs.
time consuming for implementations and without a 100% guarantee, as a Such inspection may be time consuming for implementations and without
node segment path may use LAG that could be invisible from the IP a 100% guarantee, as a node segment path may use LAGs that are
topology. A simpler approach would be to consider that a label bound invisible to the IP topology. As a simpler approach, an
to a Node-SID will be subject to load-balancing and requires an EL/ implementation MAY consider that a label bound to a Node-SID will be
ELI. subject to load-balancing and requires an ELI/EL.
7.2.2.2. Adjacency-set SID 7.2.2.2. Adjacency-set SID
An adjacency-set is an adjacency SID that refers to a set of An adjacency-set is an Adj-SID that refers to a set of adjacencies.
adjacencies. When an adjacency-set segment is used within a label When an adjacency-set segment is used within a label stack, an
stack, an implementation can deduce that load-balancing is expected implementation can deduce that load-balancing is expected at the node
at the node that advertised this adjacency segment. An that advertised this adjacency segment. An implementation MAY favor
implementation could then favor this particular label value when the insertion of an ELI/EL after the Adj-SID representing an
placing ELI/ELs. adjacency-set.
7.2.2.3. Adjacency-SID representing a single IP link 7.2.2.3. Adjacency-SID representing a single IP link
When an adjacency segment representing a single IP link is used When an adjacency segment representing a single IP link is used
within a label stack, an implementation can deduce that load- within a label stack, an implementation can deduce that load-
balancing may not be expected at the node that advertised this balancing may not be expected at the node that advertised this
adjacency segment. adjacency segment.
The implementation could then decide to place ELI/ELs to favor other An implementation MAY NOT place an ELI/EL after a regular Adj-SID in
LSRs than the one advertising this adjacency segment. order to favor the insertion of ELI/ELs following other segments.
Readers should note that an adjacency segment representing a single Readers should note that an adjacency segment representing a single
IP link may require load-balancing. This is the case when a LAG (L2 IP link may require load-balancing. This is the case when a LAG (L2
bundle) is implemented between two IP nodes and the L2 bundle SR bundle) is implemented between two IP nodes and the L2 bundle SR
extensions [I-D.ietf-isis-l2bundles] are not implemented. In such a extensions [I-D.ietf-isis-l2bundles] are not implemented. In such a
case, it may be useful to insert an EL/ELI in a readable position for case, it could be useful to insert an ELI/EL in a readable position
the LSR advertising the label associated with the adjacency segment. for the LSR advertising the label associated with the adjacency
segment. To communicate the requirement for load-balancing for a
particular Adjacency-SID to ingress nodes, a user can enforce the use
of the L2 bundle SR extensions defined in [I-D.ietf-isis-l2bundles]
or can declare the single adjacency as an adjacency-set.
7.2.2.4. Adjacency-SID representing a single link within a L2 bundle 7.2.2.4. Adjacency-SID representing a single link within an L2 bundle
When L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, When the L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used,
adjacency segments may be advertised for each member of the bundle. adjacency segments may be advertised for each member of the bundle.
In this case, an implementation can deduce that load-balancing is not In this case, an implementation can deduce that load-balancing is not
expected on the LSR advertising this segment and could then decide to expected on the LSR advertising this segment and MAY NOT insert an
place ELI/ELs to favor other LSRs than the one advertising this ELI/EL after the corresponding label.
adjacency segment.
7.2.2.5. Adjacency-SID representing a L2 bundle 7.2.2.5. Adjacency-SID representing an L2 bundle
When L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, an When the L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used,
adjacency segment may be advertised to represent the bundle. In this an adjacency segment may be advertised to represent the bundle. In
case, an implementation can deduce that load-balancing is expected on this case, an implementation can deduce that load-balancing is
the LSR advertising this segment and could then decide to place ELI/ expected on the LSR advertising this segment and MAY insert an ELI/EL
ELs to favor this LSR. after the corresponding label.
7.2.3. Maximizing number of LSRs that will load-balance 7.2.3. Maximizing number of LSRs that will load-balance
When placing ELI/ELs, an implementation may try to maximize the When placing ELI/ELs, an implementation MAY optimize the number of
number of LSRs that both need to load-balance (i.e., have ECMP paths) LSRs that both need to load-balance (i.e., have ECMP paths) and that
and that will be able to perform load-balancing (i.e., the EL label will be able to perform load-balancing (i.e., the EL label is within
is within their ERLD). their ERLD).
Let's consider a path from PE1 to PE2 using the following stack Let's consider a path from PE1 to PE2 using the following stack
pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, Service_label>. All pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, Service_label>. All
routers have an ERLD of 10, expect P1 and P2 which have an ERLD of 4. routers have an ERLD of 10, except P1 and P2 which have an ERLD of 4.
PE1 is able to push 6 labels, so only a single ELI/EL can be added. PE1 is able to push 6 labels, so only a single ELI/EL can be added.
In the example above, adding ELI/EL next to Adj_P1P2 will only allow In the example above, adding an ELI/EL after Adj_P1P2 will only allow
load-balancing at P1 while inserting it next to Adj_PE2P9, will allow load-balancing at P1 while inserting it after Adj_PE2P9, will allow
load-balancing at P2,P3 ... P9 and maximizing the number of LSRs that load-balancing at P2,P3 ... P9 and maximizing the number of LSRs that
could perform load-balancing. can perform load-balancing.
7.2.4. Preference for a part of the path 7.2.4. Preference for a part of the path
An implementation may propose to favor a part of the end-to-end path An implementation MAY allow the user to favor a part of the end-to-
when the number of EL/ELI that can be pushed is not enough to cover end path when the number of ELI/ELs that can be pushed is not enough
the entire path. As example, a service provider may want to favor to cover the entire path. As an example, a service provider may want
load-balancing at the beginning of the path or at the end of path, so to favor load-balancing at the beginning of the path or at the end of
the implementation should prefer putting the ELI/ELs near the top or path, so the implementation favors putting the ELI/ELs near the top
near of the bottom of the stack. or near of the bottom of the stack.
7.2.5. Combining criteria 7.2.5. Combining criteria
An implementation can combine multiple criteria to determine the best An implementation MAY combine multiple criteria to determine the best
EL/ELIs placement. However, combining too many criteria may lead to ELI/ELs placement. However, combining too many criteria could lead
implementation complexity and high resource consumption. Each time to implementation complexity and high resource consumption. Each
the network topology changes, a new evaluation of the EL/ELI time the network topology changes, a new evaluation of the ELI/EL
placement will be necessary for each impacted LSPs. placement will be necessary for each impacted LSPs.
8. A simple example algorithm 8. A simple example algorithm
A simple implementation might take into account ERLD when placing A simple implementation might take into account the ERLD when placing
ELI/EL while trying to minimize the number of EL/ELIs inserted and ELI/EL while trying to minimize the number of ELI/ELs inserted and
trying to maximize the number of LSRs that can load-balance. trying to maximize the number of LSRs that can load-balance.
The example algorithm is based on the following considerations: The example algorithm is based on the following considerations:
o An LSR that is limited in the number of <ELI, EL> pairs that it o An LSR that can insert a limited number of <ELI, EL> pairs should
can insert SHOULD insert such pairs deeper in the stack. insert such pairs deeper in the stack.
o An LSR should try to insert <ELI, EL> pairs at positions so that o An LSR should try to insert <ELI, EL> pairs at positions to
for the maximum number of transit LSRs, the EL occurs within the maximize the number of transit LSRs for which the EL occurs within
ERLD of those LSRs. the ERLD of those LSRs.
o An LSR should try to insert the minimum number of such pairs while o An LSR should try to insert the minimum number of such pairs while
trying to satisfy the above criteria. trying to satisfy the above criteria.
The pseudocode of the example algorithm is shown below. The pseudocode of the example algorithm is shown below.
Initialize the current EL insertion point to the Initialize the current EL insertion point to the
bottommost label in the stack that is EL-capable bottom-most label in the stack that is EL-capable
while (local-node can push more <ELI,EL> pairs OR while (local-node can push more <ELI,EL> pairs OR
insertion point is not above label stack) { insertion point is not above label stack) {
insert an <ELI,EL> pair below current insertion point insert an <ELI,EL> pair below current insertion point
move new insertion point up from current insertion point until move new insertion point up from current insertion point until
((last inserted EL is below the ERLD) AND (ERLD > 2) ((last inserted EL is below the ERLD) AND (ERLD > 2)
AND AND
(new insertion point is EL-capable)) (new insertion point is EL-capable))
set current insertion point to new insertion point set current insertion point to new insertion point
} }
Figure 7: Example algorithm to insert <ELI, EL> pairs in a label Figure 8: Example algorithm to insert <ELI, EL> pairs in a label
stack stack
When this algorithm is applied to the example described in Section 3, When this algorithm is applied to the example described in Section 3,
it will result in ELs being inserted in two positions, one below the it will result in ELs being inserted in two positions, one after the
label L_N-D and another below L_N-P3. Thus the resulting label stack label L_N-D and another after L_N-P3. Thus, the resulting label
would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL> stack would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL>
9. Deployment Considerations 9. Deployment Considerations
As long as LSR node dataplane capabilities are limited (number of As long as LSR node dataplane capabilities are limited (number of
labels that can be pushed, or number of labels that can be labels that can be pushed, or number of labels that can be
inspected), hop-by-hop load-balancing of SPRING encapsulated flows inspected), hop-by-hop load-balancing of SPRING encapsulated flows
will require trade-offs. will require trade-offs.
Entropy label is still a good and usable solution as it allows load- The entropy label is still a good and usable solution as it allows
balancing without having to perform a deep packet inspection on each load-balancing without having to perform deep packet inspection on
LSR: it does not seem reasonable to have an LSR inspecting UDP ports each LSR: it does not seem reasonable to have an LSR inspecting UDP
within a GRE tunnel carried over a 15 label SPRING tunnel. ports within a GRE tunnel carried over a 15 label SPRING tunnel.
Due to the limited capacity of reading a deep stack of MPLS labels, Due to the limited capacity of reading a deep stack of MPLS labels,
multiple EL/ELIs may be required within the stack which directly multiple ELI/ELs may be required within the stack which directly
impacts the capacity of the head-end to push a deep stack: each EL/ impacts the capacity of the head-end to push a deep stack: each ELI/
ELI inserted requires two additional labels to be pushed. EL inserted requires two additional labels to be pushed.
Placement strategies of EL/ELIs are required to find the best trade- Placement strategies of ELI/ELs are required to find the best trade-
off. Multiple criteria may be taken into account and some level of off. Multiple criteria could be taken into account and some level of
customization (by the user) may be required to accommodate the customization (by the user) is required to accommodate different
different deployments. Analyzing the path of each destination to deployments. Since analyzing the path of each destination to
determine the best EL/ELI placement may be time consuming for the determine the best ELI/EL placement may be time consuming for the
control plane, we encourage implementations to find the best trade- control plane, we encourage implementations to find the best trade-
off between simplicity, resource consumption, and load-balancing off between simplicity, resource consumption, and load-balancing
efficiency. efficiency.
In future, hardware and software capacity may increase dataplane In the future, hardware and software capacity may increase dataplane
capabilities and may be remove some of these limitations, increasing capabilities and may remove some of these limitations, increasing
load-balancing capability using entropy labels. load-balancing capability using entropy labels.
10. Options considered 10. Options considered
Different options that were considered to arrive at the recommended Different options that were considered to arrive at the recommended
solution are documented in this section. solution are documented in this section.
These options are detailed here only for historical purposes. These options are detailed here only for historical purposes.
10.1. Single EL at the bottom of the stack 10.1. Single EL at the bottom of the stack
skipping to change at page 21, line 19 skipping to change at page 22, line 43
recommended solution in Section 7. recommended solution in Section 7.
Note that a refinement of this solution which balances the number of Note that a refinement of this solution which balances the number of
pushed labels against the desired entropy is the solution described pushed labels against the desired entropy is the solution described
in Section 7. in Section 7.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank John Drake, Loa Andersson, Curtis The authors would like to thank John Drake, Loa Andersson, Curtis
Villamizar, Greg Mirsky, Markus Jork, Kamran Raza, Carlos Pignataro, Villamizar, Greg Mirsky, Markus Jork, Kamran Raza, Carlos Pignataro,
Bruno Decraene, Chris Bowers and Nobo Akiya for their review comments Bruno Decraene, Chris Bowers, Nobo Akiya, Daniele Ceccarelli and Joe
and suggestions. Clarke for their review comments and suggestions.
12. Contributors 12. Contributors
Xiaohu Xu Xiaohu Xu
Huawei Huawei
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Wim Hendrickx Wim Hendrickx
Nokia Nokia
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
skipping to change at page 22, line 7 skipping to change at page 23, line 31
Email: acee@cisco.com Email: acee@cisco.com
13. IANA Considerations 13. IANA Considerations
This memo includes no request to IANA. Note to RFC Editor: Remove This memo includes no request to IANA. Note to RFC Editor: Remove
this section before publication. this section before publication.
14. Security Considerations 14. Security Considerations
This document does not introduce any new security considerations Compared to [RFC6790], this document introduces the notion of ERLD,
beyond those already listed in [RFC6790]. MSD and may require an ingress node to push multiple ELI/EL. These
changes does not introduce any new security considerations beyond
those already listed in [RFC6790].
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-13 data plane", draft-ietf-spring-segment-routing-mpls-14
(work in progress), April 2018. (work in progress), June 2018.
15.2. Informative References 15.2. Informative References
[I-D.ietf-isis-mpls-elc] [I-D.ietf-isis-mpls-elc]
Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
Litkowski, "Signaling Entropy Label Capability and Litkowski, "Signaling Entropy Label Capability and
Readable Label-stack Depth Using IS-IS", draft-ietf-isis- Readable Label-stack Depth Using IS-IS", draft-ietf-isis-
mpls-elc-03 (work in progress), January 2018. mpls-elc-03 (work in progress), January 2018.
[I-D.ietf-ospf-mpls-elc] [I-D.ietf-ospf-mpls-elc]
skipping to change at page 23, line 17 skipping to change at page 24, line 46
Litkowski, "Signaling Entropy Label Capability and Litkowski, "Signaling Entropy Label Capability and
Readable Label-stack Depth Using OSPF", draft-ietf-ospf- Readable Label-stack Depth Using OSPF", draft-ietf-ospf-
mpls-elc-05 (work in progress), January 2018. mpls-elc-05 (work in progress), January 2018.
[I-D.ietf-isis-l2bundles] [I-D.ietf-isis-l2bundles]
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
E. Aries, "Advertising L2 Bundle Member Link Attributes in E. Aries, "Advertising L2 Bundle Member Link Attributes in
IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
May 2017. May 2017.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>.
[I-D.ietf-isis-segment-routing-msd]
Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling MSD (Maximum SID Depth) using IS-IS", draft-
ietf-isis-segment-routing-msd-12 (work in progress), May
2018.
[I-D.ietf-ospf-segment-routing-msd]
Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
"Signaling MSD (Maximum SID Depth) using OSPF", draft-
ietf-ospf-segment-routing-msd-14 (work in progress), May
2018.
[I-D.ietf-idr-bgp-ls-segment-routing-msd]
Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan,
"Signaling Maximum SID Depth using Border Gateway Protocol
Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01
(work in progress), October 2017.
Authors' Addresses Authors' Addresses
Sriganesh Kini Sriganesh Kini
EMail: sriganeshkini@gmail.com EMail: sriganeshkini@gmail.com
Kireeti Kompella Kireeti Kompella
Juniper Juniper
EMail: kireeti@juniper.net EMail: kireeti@juniper.net
 End of changes. 123 change blocks. 
335 lines changed or deleted 427 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/