draft-ietf-mpls-spring-entropy-label-08.txt   draft-ietf-mpls-spring-entropy-label-09.txt 
Network Working Group S. Kini Network Working Group S. Kini
Internet-Draft Internet-Draft
Intended status: Informational K. Kompella Intended status: Informational K. Kompella
Expires: August 3, 2018 Juniper Expires: October 28, 2018 Juniper
S. Sivabalan S. Sivabalan
Cisco Cisco
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
Google Google
J. Tantsura J. Tantsura
January 30, 2018 April 26, 2018
Entropy label for SPRING tunnels Entropy label for SPRING tunnels
draft-ietf-mpls-spring-entropy-label-08 draft-ietf-mpls-spring-entropy-label-09
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 when applied describes how ELs are to be applied to Segment Routing MPLS.
to the MPLS dataplane.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 3, 2018. This Internet-Draft will expire on October 28, 2018.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4
3. Use-case requiring multipath load-balancing . . . . . . . . . 4 3. Use-case requiring multipath load-balancing . . . . . . . . . 4
4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 5 4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 6
5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7 5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7
6. LSP stitching using the binding SID . . . . . . . . . . . . . 8 6. LSP stitching using the binding SID . . . . . . . . . . . . . 9
7. Insertion of entropy labels for SPRING path . . . . . . . . . 10 7. Insertion of entropy labels for SPRING path . . . . . . . . . 10
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
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 11
7.1.2. Example 2 where the ingress node has not a sufficient 7.1.2. Example 2 where the ingress node has not a sufficient
MSD . . . . . . . . . . . . . . . . . . . . . . . . . 12 MSD . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Considerations for the placement of entropy labels . . . 12 7.2. Considerations for the placement of entropy labels . . . 13
7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 13 7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 14
7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 14 7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 14
7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 14 7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 15
7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 15 7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 15
7.2.2.3. Adjacency-SID representing a single IP link . . . 15 7.2.2.3. Adjacency-SID representing a single IP link . . . 15
7.2.2.4. Adjacency-SID representing a single link within a 7.2.2.4. Adjacency-SID representing a single link within a
L2 bundle . . . . . . . . . . . . . . . . . . . . 15 L2 bundle . . . . . . . . . . . . . . . . . . . . 16
7.2.2.5. Adjacency-SID representing a L2 bundle . . . . . 15 7.2.2.5. Adjacency-SID representing a L2 bundle . . . . . 16
7.2.3. Maximizing number of LSRs that will load-balance . . 15 7.2.3. Maximizing number of LSRs that will load-balance . . 16
7.2.4. Preference for a part of the path . . . . . . . . . . 16 7.2.4. Preference for a part of the path . . . . . . . . . . 16
7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 16 7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 17
8. A simple example algorithm . . . . . . . . . . . . . . . . . 16 8. A simple example algorithm . . . . . . . . . . . . . . . . . 17
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 17 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 18
10. Options considered . . . . . . . . . . . . . . . . . . . . . 18 10. Options considered . . . . . . . . . . . . . . . . . . . . . 18
10.1. Single EL at the bottom of the stack . . . . . . . . . . 18 10.1. Single EL at the bottom of the stack . . . . . . . . . . 18
10.2. An EL per segment in the stack . . . . . . . . . . . . . 18 10.2. An EL per segment in the stack . . . . . . . . . . . . . 19
10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 19 10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 19
10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 19 10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 20
10.5. ELs at readable label stack depths . . . . . . . . . . . 20 10.5. ELs at readable label stack depths . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14. Security Considerations . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 21 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 22 15.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 with an associated MPLS label value. Hence, label stacking is
used to represent the ordered list of segments and the label stack used to represent the ordered list of segments and the label stack
associated with an SR tunnel can be seen as nested LSPs (LSP associated with an SR tunnel can be seen as nested LSPs (LSP
hierarchy) in the MPLS architecture. hierarchy) in the MPLS architecture.
Using label stacking to encode the list of segment has implications Using label stacking to encode the list of segment has implications
on the label stack depth. on the label stack depth.
Entropy label (EL) [RFC6790] is a technique used in the MPLS data Traffic load-balancing over ECMP (Equal Cost MultiPath) or LAGs (Link
plane to provide entropy for load-balancing. When using LSP Aggregation Groups) is usually based on a hashing function. The
hierarchies, there are implications on how [RFC6790] should be local node who performs the load-balancing is required to read some
applied. The current document addresses the case where a hierarchy header fields in the incoming packets and then computes a hash based
is created at a single LSR as required by Segment Routing. on these fields. The result of the hash is finally mapped to a list
of outgoing nexthops. The hashing technique is required to perfom a
per-flow load-balancing and thus prevent packet disordering. For IP
traffic, the usual fields that are looked up are the source address,
the destination address, the protocol type, and, if the upper layer
is TCP or UDP, the source port and destination port can be added as
well in the hash.
The MPLS architecture brings some challenges on the load-balancing as
an LSR (Label Switch Router) should be able to look at header fields
that are beyond the MPLS label stack. An LSR must perform a deeper
inspection compared to an ingress router which could be challenging
for some hardware. Entropy label (EL) [RFC6790] is a technique used
in the MPLS data plane to provide entropy for load-balancing. The
idea behind entropy label is that the ingress router computes a hash
based on several fields from a given packet and place the result in
an additional label, named "entropy label". When using entropy
label, an LSR is only required to hash on the MPLS label stack or
solely on the entropy label to get a full benefit of load-balancing;
deep hashing is not required anymore.
When using LSP hierarchies, there are implications on how [RFC6790]
should be applied. The current document addresses the case where a
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
purposes in Section 10. purposes in Section 10.
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 5, line 22 skipping to change at page 5, line 40
to the node SID of LSR D. For simplicity lets assume that all LSRs to the node SID of LSR D. For simplicity lets assume that all LSRs
use the same label space (SRGB) for source routed label stacks. Let use the same label space (SRGB) for source routed label stacks. Let
L_N-Px denote the label to be used to reach the node SID of LSR Px. L_N-Px denote the label to be used to reach the node SID of LSR Px.
Let L_A-Ln denote the label used for the adjacency SID for link Ln. Let L_A-Ln denote the label used for the adjacency SID for link Ln.
The LSR S must use the label stack <L_N-P3, L_A-L1, L_N-D> for The LSR S must use the label stack <L_N-P3, L_A-L1, L_N-D> for
traffic-engineering. However to achieve good load-balancing over the traffic-engineering. However to achieve good load-balancing over the
equal cost paths P2-P4-D, P2-P5-D and the parallel links L3, L4, a equal cost paths P2-P4-D, P2-P5-D and the parallel links L3, L4, a
mechanism such as Entropy labels [RFC6790] should be adapted for mechanism such as Entropy labels [RFC6790] should be adapted for
source routed label stacks. Indeed, the SPRING architecture with the source routed label stacks. Indeed, the SPRING architecture with the
MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) uses nested MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) uses nested
MPLS LSPs composing the source routed label stacks. As each MPLS MPLS LSPs composing the source routed label stacks.
node may have limitations in the number of labels it can push when it
is ingress or inspect when doing load-balancing, an entropy label An MPLS node may have limitations in the number of labels it can
insertion strategy becomes important to keep the benefit of the load- push. It may also have a limitation in the number of labels it can
balancing. Multiple ways to apply entropy labels were considered and inspect when looking for hash keys during load-balancing. While
are documented in Section 10 along with their trade-offs. A entropy label is normally inserted at the bottom of the transport
recommended solution is described in Section 7. tunnel, this may prevent an LSR to take into account the EL in its
load-balancing function if the EL is too deep in the stack. In a
segment routing environment, it is important to define the
considerations that needs to be taken into account when inserting EL.
Multiple ways to apply entropy labels were considered and are
documented in Section 10 along with their trade-offs. A recommended
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.
skipping to change at page 9, line 15 skipping to change at page 9, line 40
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 term of packet forwarding, by learning the mapping-server
advertisement from PE5, 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 destinated to PE2. SPRING routers along the shortest path to PE2
will switch the traffic until it reaches P5 which will perform the will switch the traffic until it reaches P5 which will perform the
LSP stitching. P5 will swap the SPRING label 1020 to the LDP label LSP stitching. P5 will swap the SPRING label 1020 to the LDP label
20 advertised by the nexthop P6. P6 will then forward the packet 20 advertised by the nexthop P6. P6 will then 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.
skipping to change at page 22, line 22 skipping to change at page 22, line 41
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]
Filsfils, C., Previdi, S., Bashandy, A., 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-11 data plane", draft-ietf-spring-segment-routing-mpls-13
(work in progress), October 2017. (work in progress), April 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]
 End of changes. 22 change blocks. 
42 lines changed or deleted 70 lines changed or added

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