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

[Susan Hares <[e-mail]>]

Eric: 

The WG is going undertake a second generation flow specification that provides another encoding for the flow specifications for v4 and v6.   These specifications will be developed together in one document.  The initial discussions on the second generation have been going on for 2 years.  

As a WG chair, John and I wanted to stabilize the error fixes current version called for by operators (RFC5575bis, draft-ietf-idr-flow-spec-v6, and draft-ietf-idr-bgp-flowspec-oid-12) prior to launching into the second version. 

Donald Eastlake has a wonderful review, and we will address these things within a week.  The author team prioritized security and your concerns above these for this Thursday. 

Susan Hare s

-----Original Message-----
From: Eric Vyncke (evyncke) [mailto:[e-mail]] 
Sent: Thursday, November 5, 2020 9:00 AM
To: Susan Hares; 'Christoph Loibl'
Cc: [e-mail]; [e-mail]; [e-mail]; 'The IESG'; Donald Eastlake
Subject: Re: Éric Vyncke's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

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.