[Idr] Magnus Westerlund's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund 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:
----------------------------------------------------------------------

So this is really to start a discussion of how the framework approach of this
document may not be explicit enough on what combination is actually viable
combination and have existing specification for how to deal with a number of
behaviors for tunnels. So my view after having read this one is that the
signalling is specified in a two tier fashion, with an outer encapsulation that
can be IPvX, IPvX/UDP for example and then a tunnel protocol like GRE, VXLAN,
L2TPv3. So I don't believe all combinations of outer encapsulation and tunnel
protocol is actually defined. This document does not provide a table with the
reference for where the actual data plan specification for combinations are
provided. I think it would be good if there actually existed such a table/list.

The next aspect of this discuss is the difficulty in determining if the
provided sub-TLVs are sufficient. I will mention a number of potential ones
that I wonder if they are necessary to configure these combinations.

To build on Erik Kline's discuss. So are for all these combinations when IP is
the outer encapsulation is the egress ECN behavior to correctly mark or drop
inner payload well defined. If the egress is not guaranteed to do the correct,
then I think a configuration option is required.

When using UDP encapsulation combined with IPv6 there is the question if one
can safely use zero-checksum. Per RFC 6935 and RFC 6936 some consideration is
needed to determine if the inner payload is safe to combine with zero checksum.
So this requires the combination of tunnel protocol and inner payload to
determine this. So I think some of these tunnel protocols have text on this,
but I don't know which combinations have this specified. And also here arise a
question if some of these will also need a configuration option as there exist
some inner payloads that could not be safe and thus a different tunnel with
checksum enabled may be required.

When using UDP encapsulation I am wondering over source port usage. To my
knowledge some of these protocols like VXLAN do defines that source ports are
picked randomly to ensure header hashing will provide different values for
different inner flows. So is there a need in any of this cases to identify a
single source port?

So I at least are unable to determine if this specification are containing all
necessary attributes when it doesn't have identification of what combinations
it expect to work, and what behavior on the above aspects is just working.

So lets start discussing what needs to be addressed here if any.