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

Gyan Mishra <hayabusagsm@gmail.com> Mon, 30 November 2020 23:39 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 9E1CD3A0896 for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 15:39: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 hC7xECz2--PL for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 15:39:02 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 69D643A03F4 for <lsr@ietf.org>; Mon, 30 Nov 2020 15:39:02 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id f17so73110pge.6 for <lsr@ietf.org>; Mon, 30 Nov 2020 15:39: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=InBf3j5ao9pn6HyNPxRaGRC+ILlSzq5M6LVxMpmJ6dk=; b=pXa1GjkwgMNsyU/KgbcapfaaCnl58AbMNo1kABcJoQmPXrnPlROA4pTSDXhCD0alv2 CdxUNuSi4g3iAKatVmFGOB4kdwKMV53XQpiCTX+kItkj+ASBxfg3Z8iV0itm9JTK8pIn fH2ngsxpWL+GYDpEEYI3ksjcZfGoFdSiUS44uyJQaa/kMG7U6oPYLN+98g5fDRaqbsvy bL+ztq2nztWtd2LHagtbF4bQU/ezsN0Fao4lQzEUMaMh2XdFl+HxAzCVVLD0wRKz2/OT pMRVk4VpvtIdzBD/iYkyMUQ2+IAyiKCgvmGCE3AHfDgOxen9qAiy6Tb7NXXIBSRvsuFj C1KA==
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=InBf3j5ao9pn6HyNPxRaGRC+ILlSzq5M6LVxMpmJ6dk=; b=mkLKQla0NMLVpcb1rpUuyx1vy4RK3BUdqkgDDeEHC9HKuI7LR30/u/pzOzWedrBE8p p7pxmK3G/7zg4Uv7kZiplHyxLLvvFH6xbEZa1qBbycXcNHlDtJ4SFdKTkK98FniyIGKr T2jtKb+bNERBM+cap/WG9n2+GVGqfsFKKqgrQcJnwqJRNgffyWnVrM5DN6STgGHU1hqD 3fWCQlh/GjM5QFybqG5b/kn0X21MwjEnsIEayMn2j024MnTB+9/uS4H1kyT1rzG41zRP DbuHiEWYApGrHDZ1kn3+XYP3kJH3BPqR+jfjgEW4BzELeAQP5XfMiYzDZ3IJeyqm7fRO VjJw==
X-Gm-Message-State: AOAM532gTjll6umdH9J+4uIRLC0Oj4OsYhCX4stLccRKxrFAW25wFqaI MfD3lQrZHb0ex9Dt2Ahu+s1bwPaIufYyUJR57YXJjARjeoQ=
X-Google-Smtp-Source: ABdhPJwGKYW8wXuAQX88UEiR6jgiIfhq6gTyaK3BSqH0bxgi1SUDQeeAnWbQpVTHL8K59KagT2bRZclUZqLkbicNxuo=
X-Received: by 2002:a63:887:: with SMTP id 129mr3699996pgi.383.1606779541864; Mon, 30 Nov 2020 15:39:01 -0800 (PST)
MIME-Version: 1.0
References: <CABNhwV3FGcEarfQH-SVuCCdgkNJnODwRrLSK3XhefQkt1Pws0A@mail.gmail.com> <6D7A677C-86BC-4A96-8C7B-70B0563631BE@cisco.com> <CABNhwV1h2B5VZNBcZmMT0ysFTCfqnU+nVCS-x01tDR_UUmyDwg@mail.gmail.com> <B48A8996-0E10-4818-81BC-47E1F2141244@cisco.com>
In-Reply-To: <B48A8996-0E10-4818-81BC-47E1F2141244@cisco.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 30 Nov 2020 18:32:30 -0500
Message-ID: <CABNhwV1meUxzqWxrL7RzL-zjZ+eq+pkPPoFJger9juiiiDJzzg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d3471405b55b83f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ddDyrAbsbwWQAJdNH0sWk1gaIzo>
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 23:39:05 -0000

Understood.  I think the gap as you stated as far as ECMP hash algorithm
for IPv6 is vendor specific implementation which is independent of LSR.
This is a vendor implementation question and not a LSR question.

Cheers,

Gyan

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

> There is nothing in OSPF or IS-IS protocols related to the ECMP
> load-balancing with respect to the flow label. RFC 6437 is an IPv6 WG
> (predecessor of 6MAN) document. Are you just trying to torment me 😉
>
>
>
> Acee
>
>
>
> *From: *Gyan Mishra <hayabusagsm@gmail.com>
> *Date: *Monday, November 30, 2020 at 4:23 PM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *lsr <lsr@ietf.org>
> *Subject: *Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP
> / LAG / MLAG hash
>
>
>
> 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
>
>
>
>
>
> --
>
> *Error! Filename not specified.* <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
>
>
>
> --
>
> [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