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

[Robert Raszuk <[e-mail]>]

Hi Eric,

> Why was this not considered by the authors ? Or is there another document
in the WG to address this issue ?

Actually it was considered :) I wrote the first version of this draft and
after discussion with co-authors and industry peers we decided to make any
extension header extensions for flow-spec to be out of scope of the base
document.

The main reason was (and I believe still is) fact that extensions headers
are work in progress and the number of extension headers are being defined.

So while it is clearly valid to have this Next Header check we were for now
trying to focus on base IPv6 header to provide analogy to IPv4 header
functionality.

If you think this is a show stopper I guess we would need to go back to the
drawing board and halt all progress made with this document that far.

Many thx,
R.

On Wed, Nov 4, 2020 at 8:35 AM Éric Vyncke via Datatracker <[e-mail]>
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-idr-flow-spec-v6-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. It is indeed due time to
> filter
> also those IPv6 packets ;-)
>
> Please find below one blocking DISCUSS point, some non-blocking COMMENT
> points,
> and some nits.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == 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 ?
>
>
> ----------------------------------------------------------------------
> 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 ?
>
> -- 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.
>
> -- Section 3.6 --
> Just curious ;-) Why is bit 7 not used in this encoding ?
>
> -- Section 3.7 --
> I share Ben Kaduk's concern about the encoding of the flow label in less
> than
> 20 bits.
>
> == NITS ==
>
> -- Section 3.1 (and possibly others) --
> Sometimes the field 'length' is all lower case and sometimes it is
> capitalized.
>
> -- Section 3.8.2 (and possibly others) --
> Please use RFC 5952 to write IPv6 addresses.
>
>
>
>