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

["HENDERICKX Wim" <wim.henderickx at alcatel-lucent.be>]

Kireeti/Steward

Some remarks in-line regarding TTL=0 for the entropy label

Cheers,
Wim

-----Original Message-----
From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of
Stewart Bryant
Sent: woensdag 9 juli 2008 13:07
To: Kireeti Kompella; Shane Amante; Clarence Filsfils
Cc: mpls at ietf.org
Subject: [mpls] Some comments on draft-kompella-mpls-entropy-lables


              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 note 
SB> fails, it is good to have another high capacity path and if it's 
SB> ECMP you can use it for FRR, but the path itself will blackhole 
SB> 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 most 
SB> folks would call that DPI. However I agree that it 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.

WH> If we use TTL=0 and we use PHP on the egress LER with BGP shortcuts,
the packet on the egress LER will be received with TTL=0. The egress LER
will drop this packet normally.

I see 3 options for this:
1. Either use TTL=1 for the entropy label
2. Do something different for BGP shortcuts, introduce a service label
like is done for 6PE e.g., but this requires changes from today's
implementations and is always hard.
3. Avoid PHP with entropy label , but this changes again current
deployment models which is always though.

For me option 1 seems the best, unless I miss something.

   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 first 
SB> 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
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls