Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Christoph Loibl <> Wed, 04 November 2020 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E90AC3A1296; Wed, 4 Nov 2020 06:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 dJ7HYeMP3lhO; Wed, 4 Nov 2020 06:10:43 -0800 (PST)
Received: from ( [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A1EA3A0A82; Wed, 4 Nov 2020 06:10:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sgaxot2SMHJFnMnMpBVLYkT/HGQ/tJgRnT6+BizW2HQ=; b=WiB1/7US9jHJztiWofn5l3pBCM gg6+IHz99m3xS27LWUq6E8VJ98wBkagZI+GGLfeAL6xinsU020rX28ZIgOCbhv1rUu++4LzD4WwVq 9pRAeSOox3Em2Lo46cDB9DBk8rzJciY9yguOcAUixpRYDcNTd/7UM+dEbyEY2vpRbNl9DTPRmBl1b FyMmJb91I5HUw5YBDDEtR4AI/sKRja4+KlUNKzsmLikq6Zziqog/0H3CScaigum6Yw7EjmkUygdr0 OAsYR4HBe790x5iPJij+Yfd/1f8VQB18o7ZHB8fOB46AiuEZv4dwS9C377vcreDAhR52cWAdQv4hC hI7JMSwA==;
Received: from ([] helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1kaJUe-0008IK-5v; Wed, 04 Nov 2020 15:10:33 +0100
From: Christoph Loibl <>
Message-Id: <>
Content-Type: multipart/mixed; boundary="Apple-Mail=_54373B9E-B84F-43AE-8984-1F65527DF08C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 04 Nov 2020 15:10:31 +0100
In-Reply-To: <>
Cc: The IESG <>,,,, Jie Dong <>,
To: Éric Vyncke <>
References: <>
X-Mailer: Apple Mail (2.3608.
X-Scanned-By: primary on (; Wed, 04 Nov 2020 15:10:32 +0100
Archived-At: <>
Subject: Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Nov 2020 14:10:49 -0000

Hi Éric,

Thanks for your review of the document. Please see my comments inline, I think this should clear your DISCUSS. I also attached a updated document that contains changes resulting from your comments.

Since the draft submission is closed now I will ask Alvaro to publish the changed document today.

Cheers Christoph

> I am puzzled by the absence of a flow spec for the first Next-Header being a
> specific value and by the absence of a flowspec for the occurence of any
> extension header in the extension header chain. Extension headers are an
> important difference compared to IPv4 and could be 'nasty' as well (e.g.,
> hop-by-hop header). Why was this not considered by the authors ? Or is there
> another document in the WG to address this issue ?

We discussed matching on extension headers in general. But this is a little bit of a moving target. It also seemed to have very limited advantage to match on the next-header-id values only (except for the upper-layer protocol). The flexibility to also match on the "content"/"encoding" of extension headers is not the scope of this document. Flowspec in general in its current specification (as extension of rfc5575bis) is not very extensible. The match for every new extension-header and its properties would most probably introduce a new FS component (something that is not easily possible). To overcome such limitations, there are discussions in IDR with the working title "FS 2.0" that should overcome the extensibility problem.

> == COMMENTS ==
> -- Section 3.1 --
> Smart idea to have an offset but I wonder whether "Offset < Length < 129" is
> true... Esp. with some IPv6 addresses with an embedded IPv4 address (32 bit) at
> offset 96. Isn't "Offset + Length <= 128" better ?

No, the Length is not the number of bits to match. The number of bits to match is Length - Offset. Length is the bitnumber in the address where matching ends.

> -- Section 3.3 --
> How is the upper-layer defined here? Basically, how a node can determine
> whether it is an extension header or an upper-layer header? While I agree that
> there are not too many new upper-layer protocols being specified, I would
> prefer to have a definition of "upper-layer" here either by listing (or
> referring to a IANA registry) all existing extension headers (then all 'next
> header' not being 'extension header' are by default 'upper layer') or
> vice-versa.

This is the term used in RFC8200 for the "last" next-header. It also explains how to detect the upper-layer protocol.

> -- Section 3.6 --
> Just curious ;-) Why is bit 7 not used in this encoding ?

The reason for this is to keep the flags aligned with the Fragementation-Flags in rfc5575bis (IPv4). rfc5575bis has matching on DF bit there.

> -- Section 3.7 --
> I share Ben Kaduk's concern about the encoding of the flow label in less than
> 20 bits.

I answerd this question in response on Benjamins DISCUSS. 

> == NITS ==
> -- Section 3.1 (and possibly others) --
> Sometimes the field 'length' is all lower case and sometimes it is capitalized.

I updated the document accordingly

> -- Section 3.8.2 (and possibly others) --
> Please use RFC 5952 to write IPv6 addresses.

As of Benjamin's comments I also added a paragraph to explain the notation, which is needed to repress the range for the pattermatching.

Christoph Loibl | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 |