Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 14 October 2020 20:06 UTC

Return-Path: <brian.e.carpenter@gmail.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 BE4EF3A101C; Wed, 14 Oct 2020 13:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 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, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 53t0K5mdgT4W; Wed, 14 Oct 2020 13:06:15 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 4EF043A101B; Wed, 14 Oct 2020 13:06:15 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id az3so350715pjb.4; Wed, 14 Oct 2020 13:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bJyGi6DYe0BbVDIkYzgi/mHSRWYTGBolUwQ/SGXkRRU=; b=Pb6XKqA2r9nhDoh9otfi8WH3jGmjPLgFUZkjDjTm9t3GqSE1R6WrgMC0IWQhw1axzb haHutQWHIdc0hUV1/2iuzT65QP59Qg0QBNyNTHGk5+hEK2By5jOd+UhtrmisghmYI1pM f8i8pH30ADkdg0U2WIWRkbmW/eWJ5ifroOURWcxLPIjpg6/PEzlaruE2hWpkXUTjC2At fxejj1dSkS9G893IxwiLzmK9WEPlgLVuPPG0aS9Hu5yLftOQCRJUUqk7Fcl+WEjDqvTJ ptIf6s/BfosX8hcQ5wDU89XBHQNzI5o27YC7f1o9CUcmC9GGzCDcPs373D8l/uHJ6UrO 90YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bJyGi6DYe0BbVDIkYzgi/mHSRWYTGBolUwQ/SGXkRRU=; b=F6ri3xGON06GGJAWZz0KP9C/jvPgIc1XiOlzaEQOQS4XkQf+x1kUy8wj53tKfZCZC/ K+/t1OBqTrVaBTntDABlLgl6YHBNySuyUjYtheC2t8ewXz/nK4TUiH8BnxGQFotbqHPv F0IhNUphnmYR7AP1BZOVslEnjovh9mekLZEKN9/Axvwx5RT3uMX8onUzmxqUTPlW9Wcr wDdX46531sIrRpGt9Mpp1RBgJhHBXZMnY+mpWQjirW9GMbglvzJQob9TueCWckLmFc/Q NRH0O7IGKPWmfKe/Vi6mNWKMXNTjVJ4+/rJYvFPurthrQLCwO8I3H4EumZ1iIxJE6JDS etTQ==
X-Gm-Message-State: AOAM530NhYHwSHTI/dvgD5l123C6V/PNbXDgvJa/zXDRlQ0iOgrTj0Jl ClH/H39FxqqJAw0z/b0wia4QYdHX6mSXbQ==
X-Google-Smtp-Source: ABdhPJx5w9m76iSZJQKqKwKBlQzR4h10zWG+Uet6+Dn7VQYnm2xU+ZTpdNbU44c8D1mZgoQDNFnSQg==
X-Received: by 2002:a17:902:465:b029:d0:89f1:9e2a with SMTP id 92-20020a1709020465b02900d089f19e2amr636167ple.6.1602705974246; Wed, 14 Oct 2020 13:06:14 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.132.159]) by smtp.gmail.com with ESMTPSA id n203sm507085pfd.81.2020.10.14.13.06.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 13:06:13 -0700 (PDT)
To: Fernando Gont <fgont@si6networks.com>, "Dale W. Carder" <dwcarder@es.net>, Fernando Gont <fernando@gont.com.ar>
Cc: v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org
References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> <20201014161946.GA65211@dwc-desktop.local> <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <0ffdf43e-957b-f01e-c121-4fa47f67a964@gmail.com>
Date: Thu, 15 Oct 2020 09:06:10 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/UY5uqsipOTcFbn7leabG5B2UuiI>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt
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: Wed, 14 Oct 2020 20:06:17 -0000

On 15-Oct-20 05:39, Fernando Gont wrote:
...
>> I am not sure if I agree with the last paragraph of 6.1 which opines on
>> the low adoption of rfc6437-style flow label hash entropy. 
> 
> We don't argue low-entropy, but issues with the Flow  Label 
> implementation. See e.g.: 
> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/
> 
> 
> 
>> I would
>> expect that the current low adoption in ecmp implementations is a
>> chicken/egg problem.  If you have a product that needs to hash and you are
>> not confident there is enough adoption in host stacks, you are still forced
>> to hunt for entropy from the upper-protocol protocols.  Otherwise all the
>> legacy host traffic with the flow label set to 0 risks getting hashed
>> entirely to one side or face reordering.
> 
> We're just stating that there's marginal usage of the Flow Label, which 
> is what the work by Cunha et al seems to indicate. As to the possible 
> consequences, part might be LBs lagging behind host implementations. But 
> issues in the Flow Label implementation might have also discouraged its use.
> 
> That said, the important info that Section 6.1 is meant to convey is 
> that there still seems to be marginal use of the FL. And also note that 
> issues have been found in FL implementations. -- i.e., we're not trying 
> to infer why there's marginal use of the FL.
> 
> If you think this warrants some tweaks in the text, please do let us know.

I just re-read that section and sadly I think it is still correct.

   Brian (co-author of several flow label RFCs)