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

[Shane Amante <shane at castlepoint.net>]

Stewart,

Stewart Bryant 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.

Actually, I believe the point is correct.  Specifically, in operation of 
a network, it has been observed that as the number of component-links in 
a link-bundle increases, one tends to experience a higher rate of 
failure of individual component-link members, generally due to subtle 
transmission errors.  Rather than have just 1 component-link 
(experiencing only a momentary transmission problem) taking down a very 
large link-bundle, operators may over-build paths with an extra 
component-link to absorb a [brief] failure of any individual member. 
This tends to be significantly less disruptive to traffic overall.

Second, with respect to node failure, once a failure is detected (either 
through Loss of Light or, perhaps, BFD) it is *automatically* propagated 
via the IGP throughout the network.  Thus, the network should recover 
automatically in a very short period of time.  Finally, operators are 
typically aware that if they are load-balancing traffic over an ECMP 
path to alleviate capacity constraints of a single path, they could have 
(big) problems when one of the multiple paths fails.  Therefore, they 
may plan to load-balance over, say, 3x ECMP paths in order that if any 
one path fails there is only a reduction of 33% of capacity, which may 
be adequate to continue forwarding without any traffic loss.




>  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.

Although it may be a "standard tuple", the larger problem is *where to 
find it* or how deep in a packet you're going to have to search to find 
something that adequately and accurately describes a "microflow".  For 
example, consider the following very brief list of encapsulations:

IPv4/GRE/IPv4
IPv6/IPv4 (IP-in-IP)
IPv4/Ethernet(Untagged)/MPLS
IPv4/Ethernet(NxVLAN Tags)/MPLS
...



> 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?

Perhaps we should remove 'topmost' from that sentence, since 
implementations are free to do as they wish, just as long as they are 
self-consistent.  However, even if they are using the bottomost labels, 
which is better, it still ultimately resorts in "macroflows".



>   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.

I will follow-up on this in the separate thread that spawned after this 
e-mail.


>   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.

We should discuss this further.  I agree reserved labels are in 
short-supply, however having a reserved label for an ELI would seem to 
be a good use case.  A reserved label could have the advantage that HW 
would be able to quickly recognize it and not attempt to use it for a 
FIB look-up for forwarding.  (There's less that can go wrong with 
forwarding if an ELI is not dynamically signaled).

I'll follow-up on the rest later.

-shane



> 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