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

From: Gyan Mishra <[email-masked]>
Date: Tue, 8 Dec 2020 15:22:24 -0500

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Dec 2020 17:19:52 +1300

Gyan,

I'm sorry, I don't understand what your question is. The reason that RFC6437 calls for a hash algorithm with certain properties when setting the flow label is precisely so that the reulting flow label is suitable input to any further ECMP or LAG hash, with or without the traditional n-tuple being available.

There is background info in RFC6436, and specific uses cases in RFC6438 and RFC7098. Maybe you can refine your question after reviewing those RFCs?

Regards
   Brian Carpenter

On 09-Dec-20 09:22, Gyan Mishra wrote:
> 
> 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.
> 
> 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.
> 
>    The 20-bit Flow Label field in the IPv6 header [RFC2460 <https://tools.ietf.org/html/rfc2460>] is used by a
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike 
> /Silver Spring, MD
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 9 Dec 2020 01:57:56 -0500

Hi Brian

The RFCs mentioned helped a lot.

So basically my confusion was on the stateful signaled usage which is
implies the source tagging the packets and flow or session based load
balancing.

The stateless option is the mutable flow label local generation of 20 bit
hash key via 5-tuple headers to generate uniform statistical hash that
provides even per packet load balancing to avoid chance of out of order
packets.

I believe most modern routers on current code support RFC  6437 5-tuple
hash which I have to validate per vendor support and code.

This feature as mentioned is extremely valuable for operators and will help
gain momentum to push forward to accelerate deployments to IPv6 only core
moving away from MPLS and straight to SRv6 as quick as possible to reap the
benefits of 5-tuple load balancing hash.

The 5-tuple uniform statistical load balancing hash is a major gain for
IPv6 and fills a  huge gap for both MPLS and IPv4 that utilizes ECMP  flow
or session based very uneven load balancing.

I am working on an SR analysis draft that compare and contrasts SR-MPLS to
SRv6 and so this is one more major benefit for SRv6 over SR-MPLS.

MPLS has an entropy label which helps eliminate control plane and data
plane state with having to allocate additional labels per path but
unfortunately does not provide statistical uniform load balancing entropy.

https://tools.ietf.org/html/rfc6790

I have a draft on BESS WG below I presented at the last three IETFs which I
am working with 5  of the major industry stakeholder router vendors Cisco,
Juniper, Arista, Nokia and Huawei to validate a solution for RFC 5549 / RFC
8950 that allows an IPv6 peer to carry IPV4 NLRI.  The proposal is geared
to eliminate IPv4 peering at the edge PE-CE by stacking AFIs,  basically
using IPv6 peer as a pure transport to carry IPv4 NLRI AFI so AFI/SAFI 1/1
2/1 are carried over 2/1.

BGP AFI SAFI
https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/

IETF 109 BESS presentation- look for Gyan

https://datatracker.ietf.org/meeting/agenda/

This draft also resolves IPv4 address depletion issue at IXP peering points
as now IPv4 can be 100% eliminated from all PE-CE peering worldwide for
both enterprises and service providers.

With this draft the operator core will now be 100% pure IPv6  only from the
P core to the PE edge customer peering.  So all that will be v4 is the
customer payload overlay.

As we do the vendor QA for the draft mentioned, we will also try to add in
RFC 6437 5-tuple stateless statistical load balancing to ensure that works
without issue.

I am going to try to spin up another draft to tackle this effort for QA
testing of RFC 6437 for 5-tuple ECMP hash entropy key uniform statistical
load balancing.  I think v6ops would be the right spot as we would be QA
testing of uniform load balancing to provide valuable data point for
operators to give another reason to move towards IPv6 only SRv6 core.

Thank you

Gyan

On Tue, Dec 8, 2020 at 11:19 PM Brian E Carpenter <
[email-masked]> wrote:

> Gyan,
>
> I'm sorry, I don't understand what your question is. The reason that
> RFC6437 calls for a hash algorithm with certain properties when setting the
> flow label is precisely so that the reulting flow label is suitable input
> to any further ECMP or LAG hash, with or without the traditional n-tuple
> being available.
>
> There is background info in RFC6436, and specific uses cases in RFC6438
> and RFC7098. Maybe you can refine your question after reviewing those RFCs?
>
> Regards
>    Brian Carpenter
>
> > 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.
> >
> > 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
> > 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.
> >
> > 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
> > 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
> > The maximum lifetime of any flow-handling state established along a
> flow's path must be specified as part of the description of the
> >    The 20-bit Flow Label field in the IPv6 header [RFC2460 <
> https://tools.ietf.org/html/rfc2460>] is used by a

*Gyan Mishra*