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

["Vishwas Manral" <vishwas.ietf at gmail.com>]

Hi Stewart/ Kireeti,

I personally find the draft very helpful though I cannot find link to
the draft, this is the exact point I raised on the other drafts too,
the idea of Flow labels being used.
http://www.ietf.org/mail-archive/web/mpls/current/msg02080.html

Kireeti, there are other advantages of flow labels I had mentioned in
my earlier mail, besides ECMP. You may want to include that in your
draft too. Having worked on middle boxes these are very real issues.

Some other things to consider are, reserved labels not being the
bottom of stack always and deriving information of the bottom of stack
from the last label, and deriving information like the packet protocol
(IPv4 or IPv6 based on that label).

Thanks,
Vishwas

On Wed, Jul 9, 2008 at 4:07 AM, Stewart Bryant <stbryant at cisco.com> wrote:
>
>             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
>
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls