Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels
RFC 8662

Document Type RFC - Proposed Standard (December 2019; No errata)
Authors Sriganesh Kini  , Kireeti Kompella  , Siva Sivabalan  , Stephane Litkowski  , Rob Shakir  , Jeff Tantsura 
Last updated 2019-12-06
Replaces draft-kini-mpls-spring-entropy-label
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Loa Andersson
Shepherd write-up Show (last changed 2018-07-04)
IESG IESG state RFC 8662 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Deborah Brungard
Send notices to draft-ietf-mpls-spring-entropy-label@ietf.org, mpls@ietf.org, db3546@att.com
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions

Internet Engineering Task Force (IETF)                           S. Kini
Request for Comments: 8662                                              
Category: Standards Track                                    K. Kompella
ISSN: 2070-1721                                                  Juniper
                                                            S. Sivabalan
                                                            S. Litkowski
                                                               R. Shakir
                                                             J. Tantsura
                                                            Apstra, Inc.
                                                           December 2019

 Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels


   Segment Routing (SR) leverages the source-routing paradigm.  A node
   steers a packet through an ordered list of instructions, called
   segments.  Segment Routing can be applied to the Multiprotocol Label
   Switching (MPLS) data plane.  Entropy labels (ELs) are used in MPLS
   to improve load-balancing.  This document examines and describes how
   ELs are to be applied to Segment Routing MPLS.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Abbreviations and Terminology
   3.  Use Case Requiring Multipath Load-Balancing
   4.  Entropy Readable Label Depth
   5.  Maximum SID Depth
   6.  LSP Stitching Using the Binding SID
   7.  Insertion of Entropy Labels for SPRING Path
     7.1.  Overview
       7.1.1.  Example 1: The Ingress Node Has a Sufficient MSD
       7.1.2.  Example 2: The Ingress Node Does Not Have a Sufficient
     7.2.  Considerations for the Placement of Entropy Labels
       7.2.1.  ERLD Value
       7.2.2.  Segment Type
       7.2.3.  Maximizing Number of LSRs That Will Load-Balance
       7.2.4.  Preference for a Part of the Path
       7.2.5.  Combining Criteria
   8.  A Simple Example Algorithm
   9.  Deployment Considerations
   10. Options Considered
     10.1.  Single EL at the Bottom of the Stack
     10.2.  An EL per Segment in the Stack
     10.3.  A Reusable EL for a Stack of Tunnels
     10.4.  EL at Top of Stack
     10.5.  ELs at Readable Label Stack Depths
   11. IANA Considerations
   12. Security Considerations
   13. References
     13.1.  Normative References
     13.2.  Informative References
   Authors' Addresses

1.  Introduction

   Segment Routing [RFC8402] is based on source-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 data plane [RFC8660],
   each segment is an LSP (Label Switched Path) with an associated MPLS
   label value.  Hence, label stacking is used to represent the ordered
   list of segments, and the label stack associated with an SR tunnel
   can be seen as nested LSPs (LSP hierarchy) in the MPLS architecture.

   Using label stacking to encode the list of segments has implications
   on the label stack depth.

   Traffic load-balancing over ECMP (Equal-Cost Multipath) or LAGs (Link
   Aggregation Groups) is usually based on a hashing function.  The
   local node that performs the load-balancing is required to read some
   header fields in the incoming packets and then compute a hash based
   on those fields.  The result of the hash is finally mapped to a list
   of outgoing next hops.  The hashing technique is required to perform
Show full document text