Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / MLAG hash

Gyan Mishra <hayabusagsm@gmail.com> Mon, 30 November 2020 20:58 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C3A3A118C for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 12:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD-FNCthhdYi for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 12:58:02 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D703A1199 for <lsr@ietf.org>; Mon, 30 Nov 2020 12:58:02 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id y7so11194033pfq.11 for <lsr@ietf.org>; Mon, 30 Nov 2020 12:58:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+XXkSC2XAJdN1ldEUo4ItNT7fcW+KRNHHBKcpuN0OtY=; b=e+sFJmR4c+At/a+xiyKy/luSS1pQonTNEYdI+JKMu/PSAXE/f4mVLqnI/qfrVwapDN 1Q5i3zBQiz3qH4SNQPEDg/N9Cc6cZq7kHIh8R0vUw+nWm9owfY6BqR8J/GGxlQKusnFy 3azRBIK84AGtQWvjWYEGQPo7hNv4qbFKldr1fyEx7CKrjoHwuzaGa2Y/hhW5TrobfQEO dx3+osn4pAw8ldNBqOU195huff0NksjVQ+DnHlXGo+B9BYytWHuWVR8DbBQ4olxPadSu S7ldvO0aC1b41YAendy3ylHUJY9ErEpudL/6+PGteWiK+tuZ7RJGcat+PNEyF6WF+Hfc bFwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+XXkSC2XAJdN1ldEUo4ItNT7fcW+KRNHHBKcpuN0OtY=; b=BmASOFoBnoZgj6teBT7QHxdJE3W+6Ipc1Ra+1AkvdqaHtWvpBXm2VbB5dN3fzzWhz9 KJXLxhT+4LQpMGsmIiMDqVUnAy3tIYEIBEtOjZfcW+p3X2TETx6q7+d/tXJKJSTkdlV1 BYQg4GoPrSvt/DeypwYhJt6isEIvD2EBnPYWuEZujTvLW5e7WG5qWySrYocem2KOAtMY EUvhqkMKnwnXauHjK3LW43f9LclmoYRRSGODMLna6FTMquhLGOIJMSM+kep4HMTonHZA rwX6ho1qMIvrrspiIej+6UtriXYkmc6q0hIwtykysDq+pMydoN6eRHa58lswXtE+xwSD xExQ==
X-Gm-Message-State: AOAM530og5QlHGh4pj91pK/sBKPOG11dkhHy98iiVnvBJMZmQxm0228x oTUhyXMF5acHIOtGPPYJMU3SE2svZVq9xc2M5ks=
X-Google-Smtp-Source: ABdhPJwVhDbEDkq7jkWnLL0GTBAy15mKbRQC86gdrRltaNc2bSNDAq96IU3BBXNY+fFWCZF+2wYCwnHpvKcHoz5vp7Q=
X-Received: by 2002:aa7:9af2:0:b029:198:273c:6be8 with SMTP id y18-20020aa79af20000b0290198273c6be8mr20696568pfp.4.1606769881400; Mon, 30 Nov 2020 12:58:01 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV3FGcEarfQH-SVuCCdgkNJnODwRrLSK3XhefQkt1Pws0A@mail.gmail.com> <6D7A677C-86BC-4A96-8C7B-70B0563631BE@cisco.com>
In-Reply-To: <6D7A677C-86BC-4A96-8C7B-70B0563631BE@cisco.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 30 Nov 2020 15:51:29 -0500
Message-ID: <CABNhwV3wDtsHp2FjmR8UZGVprAJ_zsk=cRD+DhKAYAzGm-6Nqw@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000044d9005b55944ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/E_MKu-ahDm8gn4Jc9Y-rSmVf6UE>
Subject: Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / MLAG hash
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2020 20:58:05 -0000

Thanks Acee.

Gyan

On Mon, Nov 30, 2020 at 3:39 PM Acee Lindem (acee) <acee@cisco.com> wrote:

> Speaking as LSR Co-Chair:
>
>
>
> Hi Gyan,
>
> This is more a discussion for the 6MAN WG. Here is the charter for the LSR
> WG: https://datatracker.ietf.org/wg/lsr/about/
>
> No need to cross-post to the LSR list…
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <lsr-bounces@ietf.org> on behalf of Gyan Mishra <
> hayabusagsm@gmail.com>
> *Date: *Monday, November 30, 2020 at 3:22 PM
> *To: *lsr <lsr@ietf.org>
> *Subject: *[Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP /
> LAG / MLAG hash
>
>
>
>
>
> Dear LSR WG experts,
>
>
>
>
>
> Does anyone know if vendors have started or plan to start supporting IPv6
> flow label 5-tuple dscp marking for ECMP hashing.
>
>
>
> IPv6 flow label support for ECMP
>
>
>
> https://tools.ietf.org/html/rfc6437
>
>
>
> IPv4 has traditionally always utilized recommended BCP of flow based load
> balancing due to issues related to out of order and reordering of packets.
> Although per packet load balancing is supported by most vendors it is not
> recommended due to forwarding plane impact.
>
>
>
> This IPv6 flow label feature of 5-tuple hash provides significant
> advantages for operators much needed ECMP load balancing entropy as compare
> to traditional “flow or session” based load balancing which is the case as
> well with MPLS entropy label RFC 6790 load balancing contrasted below.
>
>
>
> IPv6 flow label has significant  benefits for operators deploying  SRv6
> which utilizes the IPv6 data plane to now have “native” built in ECMP
> entropy as part of the protocol as compare to its predecessor IPv4.
>
>
>
> This gives SRv6 another significant edge over MPLS predecessor.
>
>
>
> Excerpt from RFC 6437:
>
>
>
>       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.
>
>
>
>
>
> Below comparison of IPv6 flow label benefits over MPLS entropy label:
>
>
>
>
>
> ! MPLS Entropy label
>
> https://tools.ietf.org/html/rfc6790
>
>
>
>
>
>
>
> As a comparison to MPLS entropy label, the mpls entropy label reduces the control plane label binding and LFIB forwarding plane data structure by not having a per ECMP path label allocation per FEC by adding an additional entropy label to the label stack.
>
>
>
>
>
> However MPLS entropy label is still uses the traditional flow or session based load balancing algorithm which results in
>
> uneven load balancing.
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>


-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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