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

From: Erik Kline via Datatracker <[email-masked]>
Date: Mon, 30 Nov 2020 21:29:02 -0800

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.

----------------------------------------------------------------------
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?

---

From: Erik Kline <[email-masked]>
Date: Mon, 30 Nov 2020 21:46:53 -0800

> https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/

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.