Re: [Idr] Erik Kline's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

[Erik Kline <[e-mail]>]

On Mon, Nov 30, 2020 at 9:29 PM Erik Kline via Datatracker
<[e-mail]> wrote:
>
> Erik Kline has entered the following ballot position for
> draft-ietf-idr-tunnel-encaps-20: 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-tunnel-encaps/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> [ section 3.3.1 ]
>
> * The text about "[a]ny one-octet value can be transported" leaves me
>   wondering about how values that result in ECN bits being set should be
>   treated.
>
>   I think there needs to be some recognition here that the DSCP part of
>   the octet is only 6 bits (2474 section 3), and that bits 6 & 7 "MUST/SHOULD
>   be zero on transmission and MUST/SHOULD be ignored by the recipient".
>
>   Another way to ask the question here is: if ECN is not to be specified as
>   part of this octet (and IMHO it should not be), which ranges of 6 bit
>   values are permitted: [0..63], with the understanding this will be shifted
>   before setting the octet, or [0,4,8,12,...,252]?  Given the text "It
>   specifies the setting of the one-octet...", I think it implies the latter,
>   but some clarification would, I think, be helpful.

If the argument is essentially: this is the value to stuff into
something like setsockopt(..., IP_TOS|IPV6_TCLASS, ...) which (in
Linux) accept an 8 bit value as is, then suppose that makes sense.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> [[ questions ]]
>
> [ section 3.1 ]
>
> * The prohibition against use of Forwardable=false egress IPs I think means
>   that IPv4 and IPv6 link-local addresses cannot be used.  It seems somewhat
>   unusual, but not completely outside the realm of reasonable, to have a
>   situation where two on-link routers could be configured by their respective
>   administrators to use some encapsulation for forwarded packets without
>   having to resort to global unicast addresses.
>
>   Are we sure this (odd) use case should be prohibited?
>
>   The final paragraph of this section seems to cover the use of non-reachable
>   addresses just fine.  Obviously link-local IPs would need to be exempt from
>   section 3.1.1 AS-owned address validation.
>
> [ section 3.3+ ]
>
> * Do any implementations wish to set IPv6 flow labels?
>
> [ section 6 ]
>
> * Might MTU overhead a consideration in tunnel selection?  I.e., given more
>   than one tunnel option might an implementation choose based on minimizing
>   total overhead?
>
>
>