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

[Alvaro Retana <[e-mail]>]

Erik:

Hi!  Happy New Year!

John just submitted -21.  Can you please take a look?  From the exchange
below, it may already address your concerns. ;-)

Please let us know if that is not the case.

Thanks!

Alvaro.

On December 2, 2020 at 3:28:30 PM, John Scudder ([e-mail]) wrote:

Hi Erik,

On Dec 1, 2020, at 12:46 AM, Erik Kline <[e-mail]> wrote:


...

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


Thanks for anticipating my reply, that was exactly the thinking.

If it makes sense, do you think the text is sufficient as written, or if
not do you have any suggestions for clarification?

Thanks,

—John