< draft-ietf-mpls-spring-entropy-label-10.txt   draft-ietf-mpls-spring-entropy-label-11.txt >
Network Working Group S. Kini Network Working Group S. Kini
Internet-Draft Internet-Draft
Intended status: Informational K. Kompella Intended status: Standards Track K. Kompella
Expires: October 29, 2018 Juniper Expires: November 24, 2018 Juniper
S. Sivabalan S. Sivabalan
Cisco Cisco
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
Google Google
J. Tantsura J. Tantsura
April 27, 2018 May 23, 2018
Entropy label for SPRING tunnels Entropy label for SPRING tunnels
draft-ietf-mpls-spring-entropy-label-10 draft-ietf-mpls-spring-entropy-label-11
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 October 29, 2018. This Internet-Draft will expire on November 24, 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . 5
4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 6 4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 6
5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7 5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7
6. LSP stitching using the binding SID . . . . . . . . . . . . . 9 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 . . . 13 7.2. Considerations for the placement of entropy labels . . . 13
7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 14 7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 43 skipping to change at page 3, line 43
well in the hash. well in the hash.
The MPLS architecture brings some challenges on the load-balancing as The MPLS architecture brings some challenges on the load-balancing as
an LSR (Label Switch Router) should be able to look at header fields 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 that are beyond the MPLS label stack. An LSR must perform a deeper
inspection compared to an ingress router which could be challenging inspection compared to an ingress router which could be challenging
for some hardware. Entropy label (EL) [RFC6790] is a technique used for some hardware. Entropy label (EL) [RFC6790] is a technique used
in the MPLS data plane to provide entropy for load-balancing. The in the MPLS data plane to provide entropy for load-balancing. The
idea behind entropy label is that the ingress router computes a hash 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 based on several fields from a given packet and place the result in
an additional label, named "entropy label". When using entropy an additional label, named "entropy label". Then, this entropy label
label, an LSR is only required to hash on the MPLS label stack or can be used as part of the hash keys used by an LSR. Using the
solely on the entropy label to get a full benefit of load-balancing; entropy label in the hash keys reduces the need of a deep packet
deep hashing is not required anymore. inspection in the LSR while keeping a good level of entropy in the
load balancing. When entropy label is used, the keys used in the
hashing functions are still a local configuration matter and an LSR
may use solely the entropy label or a combination of multiple 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
 End of changes. 6 change blocks. 
10 lines changed or deleted 14 lines changed or added

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