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

Gyan Mishra <hayabusagsm@gmail.com> Mon, 30 November 2020 21:23 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 722CA3A11BF for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 13:23:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 T4vsTR-tGieV for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 13:23:26 -0800 (PST)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 210F23A12D9 for <lsr@ietf.org>; Mon, 30 Nov 2020 13:23:14 -0800 (PST)
Received: by mail-pg1-x533.google.com with SMTP id t37so10860784pga.7 for <lsr@ietf.org>; Mon, 30 Nov 2020 13:23:14 -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=WbpExB0xfg0CzzWZZ8AuB+btBNO05AYq3+EZNSDgn7k=; b=u+W+62dDYjgcb2Iq8LV8KFE8w3IlciXP1oZ3YwTdTB7BQc5zZZWFXsb0c0pNvbywdm xRjY5jKctEpzgjEIgecddCWgJyEtclzJhEino2/tZfhR3/axSYDBLqarXQUClmiY3QKa vaZlQ2ch3Lh0C6vYGSoaZxezNoA6qh9shjiXyn8ZwWbph0AbEN663iphpVKFVJoPlpOB JfNrF2y5XGzU0mY2u0i04jh/tn5LQdXfgbawUXZj6GHYxuokMoPUsZhML2/O8/5v6EHh jbZDpCUxdSPVX4r4+wtoYvxjbft5dfuQlZW4IG406nrDqolSKOgZkLCON8784OlMsT4s VLtw==
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=WbpExB0xfg0CzzWZZ8AuB+btBNO05AYq3+EZNSDgn7k=; b=k/ejV0xGQLm//msHkoW/Oz68vjl715WH1vP3zuwapPKjksaD3lrAwNi64R2tUfQRui oFgw6gdVz7qeRYZ4heZwCW0P/Opw88E6RRj4wXD/Xt1R8//1rLoMiqCJc4nCHzF7FZYW aahHXednc/vVv8qLsOCProQ7vuPuEWayJy3Bj1hkH1u3FrzOVK8I0qGBAs81POcNsWAd mdiAYDELRdTMP3Uw6aCpXVjdf5SOfTFvvyvWkZQ10t/2d9eX3s/LMl+uMUIE0GdYM56T c6r/2zhUEt19lsVi2nGloDMsqkvHnFiIa4QNEfMgySlr4laskemBo6nFlAb1zbQNmC5P qCog==
X-Gm-Message-State: AOAM531NnQJKzseFJkh9L9ZzNOB8Lv24fB7q33DmJMy43V/BgUKmAsUu bypSZCo50ZXI+3DlX3PHdyXaCVUAGBeEzYHcq8pVZnMHVVk=
X-Google-Smtp-Source: ABdhPJwMQUJrqj/RnXwZAeZjMe3ggIUa4mgJK/koGpAZCoGyyQVKOK5iSzQeF0v+J6p+Ud370RcFpq7h27ryzG1AFR4=
X-Received: by 2002:a65:4241:: with SMTP id d1mr19207672pgq.18.1606771393555; Mon, 30 Nov 2020 13:23:13 -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 16:16:41 -0500
Message-ID: <CABNhwV1h2B5VZNBcZmMT0ysFTCfqnU+nVCS-x01tDR_UUmyDwg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000025f11405b5599e73"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6VFSdC8N34sU-7wKxQ8K2PxvNRc>
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 21:23:29 -0000

Hi Acee

6MAN deals with the IPv6 protocol specifications and not routing protocols
in the ECMP load balancing framework.

6MAN would not have any idea if ISIS or OSPF AFI IPv6 5-tuple ECMP load
balancing is supported and industry direction to support this critical
feature from a IGP perspective.

This question posed is in the context of LSR IGP load balancing framework,
OSPF & ISIS  AFI IPv6 use of RFC 6437 for 5-tuple hash ECMP load balancing
for even 50/50 load balancing hash as opposed to router default flow or
session based load balancing.

Any feedback related in this context is  much appreciated.

Kind Regards

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