Skip to main content

The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    mpls mailing list <mpls@ietf.org>,
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Protocol Action: 'The Use of Entropy Labels in MPLS Forwarding' to Proposed Standard (draft-ietf-mpls-entropy-label-06.txt)

The IESG has approved the following document:
- 'The Use of Entropy Labels in MPLS Forwarding'
  (draft-ietf-mpls-entropy-label-06.txt) as Proposed Standard

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label/


Ballot Text

Technical Summary

  Load balancing, or multi-pathing, is an attempt to balance traffic 
  across a network by allowing the traffic to use multiple paths. Load 
  balancing has several benefits: it eases capacity planning; it can 
  help absorb traffic surges by spreading them across multiple paths; 
  it allows better resilience by offering alternate paths in the event 
  of a link or node failure. 

  As providers scale their networks, they use several techniques to 
  achieve greater bandwidth between nodes. Two widely used techniques 
  are: Link Aggregation Group (LAG) and Equal-Cost Multi-Path (ECMP). 

  For MPLS networks, most of the same tecniques apply. 
  However, finding useful keys in a packet for the purpose of load 
  balancing can be more of a challenge.  In many cases, MPLS 
  encapsulation may require fairly deep inspection of packets to find 
  these keys at transit LSRs. 

  One way to eliminate the need for this deep inspection is to have the 
  ingress LSR of an MPLS Label Switched Path extract the appropriate 
  keys from a given packet, input them to its load balancing function, 
  and place the result in an additional label, termed the 'entropy 
  label', as part of the MPLS label stack it pushes onto that packet. 

  This docuement assumes that a method are used by the ingress nodes, 
  e.g. use certain fields,  termed 'keys', within a packet's header 
  as input to a load balancing function (typically a hash function) that 
  selects the path for all packets in a given flow.  

  For MPLS networks this document specifies how an entropy and entropy 
  label indicator is introduced into the label stack. In MPLS networks 
  the packet's MPLS entire label stack can then be used by transit LSRs 
  to perform load balancing, as the entropy label introduces the right 
  level of "entropy" into the label stack. 

Working Group Summary 

  This document has a strong support in the working group 
  and has been well reviewed. We have had good discussions both 
  on the mailing list and at the meetings in Paris.

  The working last call high-lighted an issues, that was decided 
  to not have an effect on this draft, but the working group chairs 
  has initiated a separate discussion that were started at the 
  Vancouver meeting. This is has to do with how an LSRs should
  behave if it can't inspect the entire label stack and how the use 
  of entropy labels will cooperate with MPLS OAM.. 

Document Quality 

  We know of one implementation, that yet has to be completed; 
  and several vendors have indicated that they intend to implement 
  this specification. 

Personnel 
  
  Loa Andersson is the document shepherd. 
  Adrian Farrel is/ the responsible AD. 

RFC Editor Note

Section 1.2
OLD
   On the other hand, an ingress LSR (e.g., a PE router) has detailed
   knowledge of an packet's contents, typically through a priori
   configuration of the encapsulation(s) that are expected at a given
   PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.).  They also have more
   flexible forwarding hardware.  PE routers need this information and
   these capabilities to:
NEW
   On the other hand, an ingress LSR (e.g., a PE router) has detailed
   knowledge of a packet's contents, typically through a priori
   configuration of the encapsulations that are expected at a given
   PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.).  They may also have
   more flexible forwarding hardware, depending on implementation
   details.  PE routers need this information and these capabilities to:
END

---

Section 3

s/[IANA MPLS Label Values]/[RFC3032]/

---

Section 4.1

s/If an ingress X/If an ingress LSR X/

---

Section 5.4

s/companion document./future document./

---

Section 8

OLD
   This section describes the use of entropy labels in various
   scenarios.
NEW
   This section describes the use of entropy labels in various
   scenarios. The material in this section is illustrative and offers
   guidance to implementations, but does not form a normative part of 
   this specification.
END

---

Section 9

OLD
   Given that there is no end-user control over the values used for
   entropy labels, there is little risk of Entropy Label forgery which
   could cause uneven load-balancing in the network.
NEW
   Given that there is no end-user control over the values used for
   entropy labels, there is little risk of Entropy Label forgery which
   could cause uneven load-balancing in the network.

   Note that if the EL value is calculated only based on packet headers,
   then a relatively efficient wiretapping interface could be added 
   depending on the function used to generate the EL value.  An
   implementation may protect against this by adding some other input to
   the generation of the EL values that would make it harder to build a
   table of EL values to tap given knowledge of the keys from the 
   packet.  For example the ingress LSR could generate a random input to
   the EL generation process.  In practice, many ECMP hashing algorithms
   contain a random factor in any case so as to avoid polarization
   issues.
END


IANA Note

   This is a "strong request" for specific allocations to facilitate early implementations.
   IANA should consider itself free to select other values if necessary, but if there is
   free choice, it would be appreciated if the values indicated below were allocated.

   In Section 10.1 the allocation of an MPLS Reserved Label is requested.
       Please allocate label 7 as the Entropy Label Indicator (ELI)

   In Section 10.2 the allocation of an LDP TLV Type is requested.
       Please allocate type 0x0206 for the Entropy Label Capability TLV

RFC Editor Note