[v6ops] RFC 6437 - IPv6 flow label usage in context of ECMP

[Gyan Mishra <[e-mail]>]

Dear v6ops & 6man,

I have a question related to how IPv6 flow label works in the context of
router ECMP load balancing characteristics resulting in even or uneven load
balancing based on the understanding flow based or n-tuple ECMP hash based
per packet algorithm.

My understanding of RFC 6437 is that the IPv6 flow label is a means of
classification of packets that are part of the same flow from a particular
flow for use in QOS marking.

>From a load balancing perspective the flow key could be used to identify a
flow and path taken on routes in a case of load balancing ECMP hash.

The goal of IPv6 flow label is for ordering of packets to be part of the
same network path in an ECMP hash resulting in flow based load balancing
identical to what exists today with IPv4.

What is confusing is if flow label 5 tuple is input to a ECMP hash
algorithm similar to LAG and MLAG which yields  per packet load balancing
based on n-tuple hash implemented by most vendors.  This would be
preferable if as it would yield even load balancing.

Or is the flow label goal to maintain the per flow load balancing and use
for QOS packet classification so all packets that are part of a particular
flow use the same ECMP path.  In this case the n-tuple hash key generated
is just to identify which path the flow had taken on a router but not an
input to a hash algorithm function as exists with LAG or MLAG.

The difference is significant as far as load balancing as a n-tuple input
to ECMP hash algorithm achieves close to 50/50 load balancing where per
flow load balancing can be uneven as it’s based on flows and thus from a
network standpoint high bandwidth flows may hash to one ECMP path and low
bandwidth flows may hash to another ECMP path.

So in general with parallel links bundling LAG and MLAG is always preferred
method for load balancing distribution over ECMP.  However L3 ECMP always
exists and is optimal to assist further load balancing which often times
exists in conjunction with LAG and MLAG.

Excerpt from a doc I found online related to IPv6 flow label operation:

A flow is a sequence of packets sent from a particular source to a
particular (unicast or multicast) destination for which the source  desires
special handling by the intervening routers. The nature of  that special
handling might be conveyed to the routers by a control  protocol, such as a
resource reservation protocol, or by information  within the flow's packets
themselves, e.g., in a hop-by-hop option.  The details of such control
protocols or options are beyond the scope of this document.

There may be multiple active flows from a source to a destination, as well
as traffic that is not associated with any flow. A flow is uniquely
identified by the combination of a source address and a  non-zero flow
label. Packets that do not belong to a flow carry a  flow label of zero.

A flow label is assigned to a flow by the flow's source node. New flow
labels must be chosen (pseudo-)randomly and uniformly from the  range 1 to
FFFFF hex. The purpose of the random allocation is to  make any set of bits
within the Flow Label field suitable for use as  a hash key by routers, for
looking up the state associated with the  flow.

All packets belonging to the same flow must be sent with the same  source
address, destination address, and flow label. If any of those packets
includes a Hop-by-Hop Options header, then they all must be  originated
with the same Hop-by-Hop Options header contents  (excluding the Next
Header field of the Hop-by-Hop Options header).  If any of those packets
includes a Routing header, then they all must be originated with the same
contents in all extension headers up to  and including the Routing header
(excluding the Next Header field in  the Routing header). The routers or
destinations are permitted, but  not required, to verify that these
conditions are satisfied. If a  violation is detected, it should be
reported to the source by an ICMP Parameter Problem message, Code 0,
pointing to the high-order octet  of the Flow Label field (i.e., offset 1
within the IPv6 packet).

The maximum lifetime of any flow-handling state established along a flow's
path must be specified as part of the description of the
state-establishment mechanism, e.g., the resource reservation  protocol or
the flow-setup hop-by-hop option. A source must not re-  use a flow label
for a new flow within the maximum lifetime of any  flow-handling state that
might have been established for the prior  use of that flow label.

Excerpt from Section 2 below:

   The 20-bit Flow Label field in the IPv6 header [RFC2460
<https://tools.ietf.org/html/rfc2460>] is used by a
   node to label packets of a flow.  A Flow Label of zero is used to
   indicate packets that have not been labeled.  Packet classifiers can
   use the triplet of Flow Label, Source Address, and Destination
   Address fields to identify the flow to which a particular packet
   belongs.  Packets are processed in a flow-specific manner by nodes
   that are able to do so in a stateless manner or that have been set up
   with flow-specific state.  The nature of the specific treatment and
   the methods for flow state establishment are out of scope for this
   specification.

   Flow label values should be chosen such that their bits exhibit a
   high degree of variability, making them suitable for use as part of
   the input to a hash function used in a load distribution scheme.  At
   the same time, third parties should be unlikely to be able to guess
   the next value that a source of flow labels will choose.


   o  Forwarding nodes such as routers and load distributors MUST NOT
      depend only on Flow Label values being uniformly distributed.  In
      any usage such as a hash key for load distribution, the Flow Label
      bits MUST be combined at least with bits from other sources within
      the packet, so as to produce a constant hash value for each flow
      and a suitable distribution of hash values across flows.
      Typically, the other fields used will be some or all components of
      the usual 5-tuple.  In this way, load distribution will still
      occur even if the Flow Label values are poorly distributed.

   Although uniformly distributed flow label values are recommended
   below, and will always be helpful for load distribution, it is unsafe
   to assume their presence in the general case, and the use case needs
   to work even if the flow label value is zero.

   As a general practice, packet flows should not be reordered, and the
   use of the Flow Label field does not affect this.  In particular, a
   Flow label value of zero does not imply that reordering is
   acceptable.



Kind Regards


Gyan


-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD