Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)
Susan Hares <shares@ndzh.com> Thu, 05 November 2020 01:03 UTC
Return-Path: <shares@ndzh.com>
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 435073A1200; Wed, 4 Nov 2020 17:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 3gTj8Dxi9XEx; Wed, 4 Nov 2020 17:02:59 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 223B83A11FE; Wed, 4 Nov 2020 17:02:58 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.115.222;
From: Susan Hares <shares@ndzh.com>
To: 'Christoph Loibl' <c@tix.at>, 'Éric Vyncke' <evyncke@cisco.com>
Cc: draft-ietf-idr-flow-spec-v6@ietf.org, idr@ietf.org, idr-chairs@ietf.org, 'The IESG' <iesg@ietf.org>
References: <160447530519.19838.7495034603697648657@ietfa.amsl.com> <C50C3710-8B0E-4B0D-B81A-533921E23D7C@tix.at>
In-Reply-To: <C50C3710-8B0E-4B0D-B81A-533921E23D7C@tix.at>
Date: Wed, 04 Nov 2020 20:02:54 -0500
Message-ID: <06dc01d6b30f$6502c510$2f084f30$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQF5oxv2FBYklenxTff5lCGtd3hzagIXdomXqmIZ4WA=
X-Antivirus: AVG (VPS 201104-7, 11/04/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jqAZJUcNrJYJh2ztSGjXxCvXuUE>
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: Thu, 05 Nov 2020 01:03:01 -0000
Eric: I want to underscore one point Christoph made for your review in the morning. The WG purpose for this version of flowspec (RFC5575-bis) was to fix existing issues (bugs, v6, within AS extension). These fixes allow the operators to continue to have DDoW work while the IDR working group to create a second revision of flow specification. Sue (co-author, WG co-chair). -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christoph Loibl Sent: Wednesday, November 4, 2020 9:11 AM To: Éric Vyncke Cc: draft-ietf-idr-flow-spec-v6@ietf.org; idr@ietf.org; idr-chairs@ietf.org; The IESG Subject: Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT) 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.
- [Idr] Éric Vyncke's Discuss on draft-ietf-idr-flo… Éric Vyncke via Datatracker
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Christoph Loibl
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Alvaro Retana
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Eric Vyncke (evyncke)
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Robert Raszuk
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Susan Hares
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Eric Vyncke (evyncke)
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Eric Vyncke (evyncke)
- Re: [Idr] Éric Vyncke's Discuss on draft-ietf-idr… Susan Hares