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

Christoph Loibl <c@tix.at> Wed, 04 November 2020 14:10 UTC

Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90AC3A1296; Wed, 4 Nov 2020 06:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at
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 dJ7HYeMP3lhO; Wed, 4 Nov 2020 06:10:43 -0800 (PST)
Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=tix.at; 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 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.64.148]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1kaJUe-0008IK-5v; Wed, 04 Nov 2020 15:10:33 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <C50C3710-8B0E-4B0D-B81A-533921E23D7C@tix.at>
Content-Type: multipart/mixed; boundary="Apple-Mail=_54373B9E-B84F-43AE-8984-1F65527DF08C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 04 Nov 2020 15:10:31 +0100
In-Reply-To: <160447530519.19838.7495034603697648657@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-idr-flow-spec-v6@ietf.org, idr-chairs@ietf.org, idr@ietf.org, Jie Dong <jie.dong@huawei.com>, aretana.ietf@gmail.com
To: Éric Vyncke <evyncke@cisco.com>
References: <160447530519.19838.7495034603697648657@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Wed, 04 Nov 2020 15:10:32 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/x1dQsxXhz8921s_bXj_6m_oFuKw>
Subject: Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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


> ## DISCUSS:
> 
> 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.

> ## COMMENT:
> == 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
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at