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

["Eric Vyncke (evyncke)" <[e-mail]>]

Susan,

First of all, I would like to congratulate the IDR WG to push forward this document shortly after the 5575-bis as promised a couple of months ago. Am I reading you well when I understand that another flow spec for IPv6 is under specification right now at the IDR WG ?

I will reply separately to Christoph and Robert's replies.

But, I forgot to mention Donald Eastlake's INT review that should also be taken into account even if not entered via the Datatracker:
https://mailarchive.ietf.org/arch/msg/last-call/fzpLblnTgGu8Rh3DOYwtqgwbj3c/

Regards

-éric

-----Original Message-----
From: Susan Hares <[e-mail]>
Date: Thursday, 5 November 2020 at 02:03
To: 'Christoph Loibl' <[e-mail]>, Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, 'The IESG' <[e-mail]>
Subject: RE: [Idr]  Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

    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:[e-mail]] On Behalf Of Christoph Loibl
    Sent: Wednesday, November 4, 2020 9:11 AM
    To: Éric Vyncke
    Cc: [e-mail]; [e-mail]; [e-mail]; 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.