Re: Comments on draft-fz-6man-ipv6-alt-mark-09

Tom Herbert <> Tue, 19 May 2020 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 042663A0AD6 for <>; Tue, 19 May 2020 09:32:52 -0700 (PDT)
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FhyEnmNihOsh for <>; Tue, 19 May 2020 09:32:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 456A73A0ACF for <>; Tue, 19 May 2020 09:32:50 -0700 (PDT)
Received: by with SMTP id d7so11982990eja.7 for <>; Tue, 19 May 2020 09:32:50 -0700 (PDT)
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:content-transfer-encoding; bh=G6NkgcMTJKjQ66pSFELeYi0LUyQyDN0Sga4T3l5QuBw=; b=cFc+b7ha9dRFwcF0iG73jYN53NZQwi02EsRXBoYMgnCYzV8/4NUXVlDfIPdwbDg3jE txZlZpZarnkqc80Hy5dsCcumuKQ87PC1iyQe9f6DrcdOfPSULBPiunpdaVWm9qB738yI 3BaNJh2yWBTJzY7D1OlH2bKFN8ESLQNUeZbL9Uj+nnJRM6P1NWqnuyVFM6ZQMvZGcmr4 niLwE8rYy5c09kGSG6EFrJeuMdHR39+QWesK+VrkCNrE58NB/GUE5iPYs7/hf5AreUq1 FNN1hE63GZma8c2Lxxws8hY8rjVkCyeyFJe65t3od1VtlbmAQT7ExIvryHMMchfu0XXF i5Zg==
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:content-transfer-encoding; bh=G6NkgcMTJKjQ66pSFELeYi0LUyQyDN0Sga4T3l5QuBw=; b=RZcDJsISucbNDj2Mf3LSAHNtpLpGyG8OTamRsOfWwYc1mbPU6mXGVYKJ7ThySgY00u q5J/aQGoFIbCvXTK4ofYvL3u27GcyrH7FmyNF4SgfTDuQwth9wa+55XFHcUQvo5sxP1h JfaVTX060V26iyFQwlb7CMPT5oLvhyUPnBh2ZEO+eDgUm/ibnf7ikeEpMo7AVaY9om7S vRzQEsZX6kyo9HqbdXoH0yz+uUeWKSnEJ4I9imlC5nF/bTdUb+1mQaLJ9obVSTTO6Do0 RRCB2VNF9p76u3lythQmrKOd0KXXHMla1zb7BOwq9SUtGbcjn3wplAYn3N5iGB0+VZjq P41Q==
X-Gm-Message-State: AOAM531Xt5oAWA46zkC+yw8SY0c1/lsddN8iQ5mTEfJF3elhgj298C3v 3XOXnGy7TWTl8w/mKN+yD8IybKX4ELH3tLrdVnKWUw==
X-Google-Smtp-Source: ABdhPJyoP1d0Ab82S5XOR5GMLLHa14TbVNIcv+pL1QyIyAmkY8QkaIAd7RjxdT+vANGtyHjyQ/kHm7WWPhVhmTVINxU=
X-Received: by 2002:a17:906:3c4f:: with SMTP id i15mr31570ejg.243.1589905968593; Tue, 19 May 2020 09:32:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 19 May 2020 09:32:37 -0700
Message-ID: <>
Subject: Re: Comments on draft-fz-6man-ipv6-alt-mark-09
To: Giuseppe Fioccola <>
Cc: Brian E Carpenter <>, 6MAN <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2020 16:32:52 -0000

On Tue, May 19, 2020 at 8:48 AM Giuseppe Fioccola
<> wrote:
> Hi Tom,
> Thanks for your support and for your comments.
> I understand your point, but, in this regard, we should consider the following paragraph from RFC6437:
>    "There is no way to verify whether a flow label has been modified en
>    route or whether it belongs to a uniform distribution.  Therefore, no
>    Internet-wide mechanism can depend mathematically on unmodified and
>    uniformly distributed flow labels; they have a "best effort" quality.
>    Implementers should be aware that the flow label is an unprotected
>    field that could have been accidentally or intentionally changed en
>    route (see Section 6)"

Hi Giuseppe,

Unless AH is present (the common case) the whole IP header and
extension headers, including any HBH and Destination Options, are also
unprotected and best effort delivery. We even have to consider that IP
addresses can change (for instance NAT can change addresses in the
middle of UDP flow lifetime).

> This does not suggest to rely fully on the Flow Label.
> Maybe we can mention in the next revision of the draft the possibility to use the Flow Label for identification, but we should also highlight this point.
> In addition, as listed in Section 5.3 of draft-fz-6man-ipv6-alt-mark-09, FlowMonID adds additional advantages in terms of scalability, flexible flow definition granularity, counters handling simplification...

I don't see any scalability for a 20 bit identifier that is supposed
to be unique throughout the network. As I mentioned this can simply be
combined with the source and destination IP addresses to form a
3-tuple. The 3-tuple can then be hashed to produce a single most
unique flow identifier that is suitable lookups. In this manner the 20
bit field is sufficient and nodes can autonomously set it without any
synchronization. This is how we commonly deal with the flow label
today and other cases of flow classification using a flow hash.

Even if the FlowMonID remains, the likely thing a host implementation
would do is just to set the FlowMonID identically to the flow label.
Do you see any reason why this won't work?


> Regards,
> Giuseppe
> -----Original Message-----
> From: ipv6 [] On Behalf Of Tom Herbert
> Sent: Tuesday, May 19, 2020 5:00 PM
> To: Brian E Carpenter <>
> Cc: 6MAN <>
> Subject: Re: Comments on draft-fz-6man-ipv6-alt-mark-09
> On Mon, May 18, 2020 at 7:39 PM Brian E Carpenter <> wrote:
> >
> > Tom,
> >
> > > It's unclear to me how the FlowMonID is set, how it's used, and why
> > > the Flow Label isn't sufficient for this purpose.
> >
> > That was proposed by the authors and discarded a long time ago,
> > because the usage was incompatible with RFC6437. I can't remember the
> > details without looking up long-expired drafts and old email. But generally:
> > you can't encode semantics in conformant flow labels, because they are
> > pseudo-random.
> >
> Brian,
> AFAICT the FlowMonID is just another type of flow identifier in the packet. For the purposes of correlating flows in the network I believe it is redundant to the flow label and would otherwise add a lot of complexity to implement. I think what you might be referring to are earlier proposals to put the loss signal bits in the flow label and not use an EH-- that idea is indeed infeasible at this point. IMO, we should be able to eliminate FlowMonID from the option, but still need the two signaling bits in the option hence the alt marking option would contain one byte of data.
> Tom
> > Regards
> >    Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------