Re: [v6ops] [tcpm] Flow Label Load Balancing

Tom Herbert <> Sun, 29 November 2020 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 116CF3A098E for <>; Sun, 29 Nov 2020 08:26:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YFpqNBdcounN for <>; Sun, 29 Nov 2020 08:26:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13F2C3A0991 for <>; Sun, 29 Nov 2020 08:26:13 -0800 (PST)
Received: by with SMTP id m16so11908976edr.3 for <>; Sun, 29 Nov 2020 08:26:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4nl8RWUyjAga5aJnJqFHpeZR5YaJoGcPySw6TFLDQYM=; b=RhHJn99s6A/08Hcn9dK+jJifriDjIwn5CxKmNsgO3AWBlhdi5+55F21nWyvHrhfzVo lK8LbKJ3y4Af8zMf1/53SM4/Zov+FzDQrdGyY1d/LyhYrjSHLIpCt1I5O6kcGST+kyxF YtxWdhDV+uWRDymRt+d2fwggj3n4ZnlefLPo7nn7r1I58aZAhUv6du7c2jWj+EdJEdsM BMmPKT+veYl0YgAQcpG1svYesFGz53vGzy8Yk0ZDAOt1RIMWuLMcv1WS5yNmWiY4kwZ7 m9M4F94RymBZyz3SF1Y9tU7ZryFtzfeQ7pRYTK0tkxAI/fGC2G6w5vyTGpyqcJ3U0qkL 0E1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4nl8RWUyjAga5aJnJqFHpeZR5YaJoGcPySw6TFLDQYM=; b=i4stFsdXvX40qsKwh0d9bvpuybHY3KHalltkKJqAuJ2bRzufdkjDwCN4bdJhDiU+mP LHmj+mCr7D6e7dHk2B2EokjAL4c8rD29I97yoEVsFO+JcVSK+1rvAwy4WOrlwESjj/QK +Yy7JLnhHKSw3mfzk9vEunqD5FwuSqS9vn4r8D0XsdfM4/GT0dPZgPcGnDAhG8eBZBJM 3JDLltZbuvHmUxL1NXGi3QKii5z2IC5eBeW19RsubCxKa2Z7DWbFQfUnKKnR/cn/yXHd zKLsLEMxE4fy+ElNm8iEIzZCVh9PF0EP5hrVzTDhHc8F4cNuH29dCewQJyX3YkGjWo+2 tomg==
X-Gm-Message-State: AOAM533gmbENqexgeRsUSXyoT6MB4APc6c/EGWFu3ILZCiJkvUvwTPaZ C8+v8ZJ29nqEnJ3C06ytPZSj7pvxeG841He+LCa/Ww==
X-Google-Smtp-Source: ABdhPJx9ImKGbB+SwsnYzYtsUAtryedC9qBssWQQMBqqzsQ92sbx0l9c//dzyrGoO1RK3B4tTNnHfEirb+P78EsJFVU=
X-Received: by 2002:aa7:dd52:: with SMTP id o18mr2084264edw.177.1606667171298; Sun, 29 Nov 2020 08:26:11 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sun, 29 Nov 2020 09:25:59 -0700
Message-ID: <>
To: Fernando Gont <>
Cc: Alexander Azimov <>, Mark Smith <>, IPv6 Operations <>, tcpm <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 29 Nov 2020 16:26:18 -0000

> Modulo the comments I've already made, I'm afraid we might be in the
> path of making the FL unusable...


I really don't understand how this makes the flow label "unusable", to
the contrary this is a useful case with good effect and justifies the
work in the host to set the field. In any case, it would be great if
you could provide the draft with the normative requirements that would
make the flow label "usable".

Please include requirements for both hosts and network nodes. If there
is going to the be a requirement that hosts MUST make a 1:1 mapping to
a transport connection and the flow label MUST be consistent for the
life of connection, then I would expect there to also be a requirement
that the flow label MUST be immutable by all devices in the path-- in
particular the requirement of RFC6437 would need to be updated: "A
forwarding node MUST either leave a non-zero flow label value
unchanged or change it only for compelling operational security
reasons..."-- if hosts are not allowed to change a field they are
primarily responsible for setting, then the network should not be
allowed to modify it either.

Additionally, if the underlying design principle is that flow
identification in a packet is immutable and persistent, then I'd like
to see the discussion on how that rectifies with NAT where
intermediate nodes routinely change IP addresses and transport port
numbers without the host endpoints' knowledge-- unlike the flow label,
port numbers are formally part of the transport connection
identification, so changing them in flight is far more invasive and
potentially harmful than changing the flow label (we've seen far more
problems caused by NAT than flow label due to NAT state evictions,
packets of a flow being re-routed to not hit the same NAT device,


> Thanks,
> --
> Fernando Gont
> e-mail: ||
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1