[mpls] Some comments on draft-kompella-mpls-entropy-lables

[Stewart Bryant <stbryant at cisco.com>]

             The Use of Entropy Labels in MPLS Forwarding
                 draft-kompella-mpls-entropy-lables


1.  Introduction

  Load balancing, or multi-pathing, is an attempt to balance traffic
  across a network by allowing the traffic to use several paths, not
  just a single shortest path.  Load balancing has several benefits: it
  eases capacity planning; it can help absorb traffic surges by
  spreading them across several links; it allow better resilience by
  offering alternate paths should a link or node fail.

SB> This last point is not correct as it stands. When a link or
SB> note fails, it is good to have another high capacity path
SB> and if it's ECMP you can use it for FRR, but the path
SB> itself will blackhole until you take action.


 There are three key
  reasons why this is beneficial:

  1.  at the ingress of the LSP, MPLS encapsulation hasn't yet
      occurred, so deep inspection is not necessary;

SB> Sure it's less deep, but it's still the standard tuple and
SB> most folks would call that DPI. However I agree that it
SB> is less deep.

1.1.  Motivation

  Currently, each MPLS LSR along a given path needs to individually
  infer the underlying protocol within a MPLS packet in order to then
  extract appropriate keys from the payload.  Those keys are then used
  as input into a hash algorithm to determine the specific output
  interface on a LSR that is used for that given "microflow".
  Unfortunately, if the MPLS LSR is unable to infer the MPLS packet's
  payload (as is often the case), they typically will resort to using
  the topmost MPLS labels in the MPLS stack as keys to the load-hashing
SB> Do you mean top or bottom?

  algorithm.  The result is an extremely inequitable distribution of
  traffic across multiple equal-cost paths exiting that node, simply
  because the topmost MPLS labels are very coarse-grained forwarding
  labels that typically describe a next-hop, or provide some other type
  of mux/demux forwarding function, and do not describe the granularity
  of the underlying traffic.

2.  Approaches


3.  Entropy Labels

  An entropy label (as used here) is a label:

  1.  that is not used for forwarding;

  2.  that is not signaled; and

  3.  whose only purpose in the label stack is to provide "entropy" to
      improve load balancing.

  Entropy labels are generated by an ingress LSR, based entirely on
  load balancing information.  However, they MUST not have values in
  the reserved label space (0-15).  Entropy labels MUST be at the
  bottom of the label stack, and thus the "end-of-stack" bit in the
  label should be set.  To ensure that they are not used inadvertently
SB> MUST be set
  for forwarding, entropy labels SHOULD have a TTL of 0.
SB> That is a good idea, we will put it in the PW draft.

  Since entropy labels are generated by the ingress LSR, an egress LSR
  MUST be able to tell unambiguously that a given label is an entropy
  label.  This of course depends on the underlying application.  If any
  ambiguity is possible, the label above the entropy label MUST be an
  "entropy label indicator" (ELI), which says that the following label
  is an entropy label.  The ELI may be signaled, or may be a reserved
  label reserved specifically for this purpose.  Fortunately, for many
  applications, the use of entropy labels is unambiguous, and does not
  need an ELI.

SB> I would be worried about using a reserved label for this.
SB> I don't think its actually needed and they are in short supply.
SB> We are going to need a forwarding path that gets context from a
SB> signaled label and discards the following label for a number of the
SB> cases, so we should try to use that method everywhere.

4.  Forwarding and Load Balancing Behaviors for Entropy Labels


  Thus, transit LSRs are almost unaffected by the use of entropy
  labels.  If transit LSRs were programmed to use a subset of the label
  stack, they may have to be reconfigured to use the full stack.  But
  otherwise, no changes are needed.

SB> Surely they just need to use the bottom of stack?


4.3.  Egress LSRs

SB> Should you consider PHP of entropy labels.



6.  Security Considerations

  Having security is a Good Thing.

SB> Firstly it's worth noting in the Security section that care is 
needed not
SB> to make this label some sort of covert channel.
SB>
SB> Secondly kind of the opposite of the above. You called it an entropy
SB> label and we (who independently thought this up) called it a load
SB> balance label. We should pick on or the other. However that causes
SB> to wonder if there is some other use that we will find for that 20
SB> bits? If so perhaps we should call it a context label?
SB> I put that remark down here because it flys in the face of my
SB> first comment about covert channels.


7.  Acknowledgments

  We wish to thank Ulrich Drafz for his contributions, as well as the
  entire "hash label" team for their valuable comments and discussion.

SB> There are so few of us we could probably be named :)




_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls