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

[Gyan Mishra <[e-mail]>]

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 <
[e-mail]> 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
>
> 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.
> >
> > 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-1347
> > 13101 Columbia Pike
> > /Silver Spring, MD
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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