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

[John Scudder <[e-mail]>]

Hi Magnus,

Thanks for your comment. My reply below.

> On Dec 3, 2020, at 5:52 AM, Magnus Westerlund via Datatracker <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!R160ShLm3-ilXKD-spxJGlwrvP9vjZX5gkLJJWWbNNKe-2FiwsoZbD19wDsUXw$
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/__;!!NEt6yMaO-gk!R160ShLm3-ilXKD-spxJGlwrvP9vjZX5gkLJJWWbNNKe-2FiwsoZbD2i6NtMNw$
> 
> 
> 
> ----------------------------------------------------------------------
> 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.

It’s not the goal of the spec to provide an all-encompassing evaluation or framework for tunneling as a data-plane technology. It would be a worthy effort to do that work, but I don’t think IDR is the right place to do it, nor do I think this document is the right document for it. The goal of the spec is restricted to signaling; more discussion below.

It’s also not the goal of the spec to support every conceivable combination in which you might construct a tunnel, it’s pragmatically oriented to things people actually wanted to ship and deploy. See also my responses to a few of the others, where I took the position that if other feature support is desired (for example, flow label), it’s up to those wanting that support to specify it.

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

I’m afraid I don’t follow this point.

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

None that’s been raised to date.

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

I guess it depends on what you mean by “necessary”. The spec has been found sufficient for at least three implementations to be shipped, so it’s demonstrably solving a real-world problem. (See the IDR wiki implementation report.) It’s been found sufficient for a number of other specs, largely in BESS, to base their functions on. (See the shepherd report.) I’m certain that if you compared the functionality that’s been implemented and/or depended on by other specs, with the complete matrix of potential functionality, you would find the surface has barely been scratched yet, which I think is fine. In that sense, I think of this spec as a framework (the attribute itself, and the TLV/sub-TLV structure within it, and their generic processing rules) plus a number of applications within that framework (the sub-TLVs). In my opinion, it would be problematic if the framework were deficient, but there is no expectation on the part of the authors or WG that every possible application has been covered, and again, that’s fine.

I expect there will be a great many extensions specified in the future.

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

Thanks,

—John