Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Fernando Gont <fgont@si6networks.com> Thu, 18 February 2021 20:05 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DCA3A1886; Thu, 18 Feb 2021 12:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jz8Ocy3nL66y; Thu, 18 Feb 2021 12:05:26 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43A13A1800; Thu, 18 Feb 2021 12:05:17 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:d092:11d0:9223:9b8f] (unknown [IPv6:2800:810:464:2b9:d092:11d0:9223:9b8f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BD4FD2807D8; Thu, 18 Feb 2021 20:05:13 +0000 (UTC)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsv-art@ietf.org
Cc: last-call@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, v6ops@ietf.org
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com> <0e377231-c319-2157-30a0-759e2f96a692@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <5f464f17-85ed-f105-35f9-02f35d04aed2@si6networks.com>
Date: Thu, 18 Feb 2021 17:04:51 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <0e377231-c319-2157-30a0-759e2f96a692@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/sON_tg3P6FINEW3fz5yCRz_7SwY>
Subject: Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 20:05:35 -0000

Hi, Brian,

On 18/2/21 16:35, Brian E Carpenter wrote:
> On 19-Feb-21 06:56, Fernando Gont wrote:
[....]
>>> * The ID also discusses use of the IPv6  Flow Label: This seems a little off
>>> topic, but seems linked to EH implications on ECMP.  However, the final
>>> sentence of this section is a reference to [Jaeggli-2018] which in turn
>>> concludes that the IPv6 Flow Label should not be used it as a part of hashes
>>> for load balancing. Yet, as far as I know, this is not the recommendation of
>>> the IETF in 2020.
>>
>> FWIW, we discuss the Flow Label a bit because the usual reaction would
>> be "why do you process the header chain for load-balancing, instead of
>> employing the Flow Label?"
> 
> However, Gorry is right that citing Joel's operational comments is only part
> of the story. I immodestly suggest citing RFC 7098 too, for a discussion
> of how the flow label can in principle be used for server load balancing.

Good grief! I thought we were referencing this one already (but looks 
like we're not) Any suggestion on how to reference it?

E.g., we could do:

    Thus, ECMP and Hash-based Load-Sharing [rfc6434] [RFC7098] should be 
possible
    without the need to process the entire IPv6 header chain to obtain
    upper-layer information to identify lows.


plus adding it ALONG WITH RFC6438 here:

    making Flow Label-based ECMP
    and Hash-based Load-Sharing [RFC6438] feasible.



xor add this:

   [RFC7098] discusses how the IPv6 FLow Label can used to enhance layer
    3/4 (L3/4) load distribution and balancing for large server farms.

right after:
    Thus, ECMP and Hash-based Load-
    Sharing should be possible without the need to process the entire
    IPv6 header chain to obtain upper-layer information to identify
    flows.



Alternatively, if you can think of a better way to do it, please do let 
us know.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492