Subject: Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19

From: "Susan Hares" <[email-masked]>
Date: Mon, 9 Nov 2020 16:26:50 -0500

Joe and Brian: 

As the replacement shepherd for draft-ietf-idr-tunnel-encaps-19.txt,  I am looking for the INT area statement on tunnels and MTU in tunnels. 

Your intarea draft seems to have expired without any replacement. 

Where is the latest set of comments on tunnels and MTU issue from INT area? 

Sue 

From: Joseph Touch [mailto:[email-masked]] 
Sent: Thursday, October 15, 2020 9:12 PM
To: Brian Trammell
Cc: tsv-art; Last Call; [email-masked]; [email-masked]
Subject: Re: [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19

On Sep 28, 2020, at 11:32 PM, Brian Trammell via Datatracker <[email-masked]> wrote:

First and foremost, I was surprised to find no reference to tunnel or MTU 
anywhere in the document, especially given the guidance in section 6 to
stack tunnels. MTU issues are operationally difficulty in single-tunnel
environments and become more likely to cause problems in multiple-tunnel
environments. 

+1

This is discussed in detail, with some much more specific terminology, in draft-ietf-intarea-tunnels

In particular, *path MTU* is different from the received MTU, etc. It’s important to get this correct (note the many examples of current standards that do not).

Joe

---

From: Joseph Touch <[email-masked]>
Date: Mon, 9 Nov 2020 13:51:55 -0800

Hi, Sue,

I have a couple of other drafts currently being wrapped up (UDP options, TCP control block sharing bis). The tunnels is next on my list and I hope to finalize a version that we can consider for WGLC by the end of the year.

That doc (even the latest expired version) has the text we’ve recommended elsewhere, e.g., in the TCP core (793) and elsewhere. 

Joe

> On Nov 9, 2020, at 1:26 PM, Susan Hares <[email-masked]> wrote:
> 
> Joe and Brian: 
>  
> From: Joseph Touch [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: tsv-art; Last Call; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Sep 28, 2020, at 11:32 PM, Brian Trammell via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>  
> _______________________________________________
> Tsv-art mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tsv-art <https://www.ietf.org/mailman/listinfo/tsv-art>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 10 Nov 2020 12:14:18 -0500

Joe: 

Could you just resubmit a version of the draft?   

We cannot reference in the draft-ietf-idr-tunnel-encaps-20.txt draft unless you have a non-expired draft.  John Scudder and the author team added it as a recommendation, but I had them take it out since the draft was expired.  IESG members do not like “expired” drafts as references. 

Here’s the current -20.txt without your draft reference. 

                 12.  Operational Considerations               

                   A potential operational difficulty arises when tunnels are used, if          

                  the size of packets entering the tunnel exceeds the maximum               

                  transmission unit (MTU) the tunnel is capable of supporting.  This         

                  difficulty can be exacerbated by stacking multiple tunnels, since            

                  each stacked tunnel header further reduces the supportable MTU.  This            

                  issue is long-standing and well-known.  The tunnel signaling provided 

                  in this specification does nothing to address this issue, nor to  

                  aggravate it (except insofar as it may further increase the         

                  popularity of tunneling).            

It would be stronger if we can point to your draft or another TSV draft that explains the details. 

If you and the TSV-art directorate has changes to this section to deal with MTU, it would very helpful  to receive this information this week. 

Cheers, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Joseph Touch
Sent: Monday, November 9, 2020 4:52 PM
To: Susan Hares
Cc: Brian Trammell; [email-masked]; [email-masked]; Last Call; tsv-art
Subject: Re: [Idr] [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19

Hi, Sue,

Joe

Joe and Brian: 

Sue 

From: Joseph Touch [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Thursday, October 15, 2020 9:12 PM
To: Brian Trammell
Cc: tsv-art; Last Call;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]
Subject: Re: [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19

On Sep 28, 2020, at 11:32 PM, Brian Trammell via Datatracker < <mailto:[email-masked]> [email-masked]> wrote:

+1

Joe

_______________________________________________
Tsv-art mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tsv-art> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Joseph Touch <[email-masked]>
Date: Tue, 10 Nov 2020 09:52:42 -0800

Hi, Sue,

It is not and cannot be a requirement. I’ve published numerous RFCs (as have others) that cite expired drafts - even those expired many years before for many reasons - sometimes to leverage their terminology or perspective, others to include their suggestions.

E.g., RFC 8899, for which 6 draft versions and the RFC were published after the latest version of the tunnels draft expired. 

Further, a quick look at the RFC Editor queue confirms that this is a ridiculous requirement. Over half of all RFCs published cite versions of drafts that had expired, given the number of weeks delay.

This is in addition to the fact that the submission queue is laughably locked (as if that prevented any WG from posting informal versions during cutoff),.

I encourage you to consult the expired version for information on why “MTU” itself is not defined (there are many variants of MTU) and for information about how to deal with layering, just as at least three other published RFCs 

I cannot speak for the IESG, but I know I have better things to do than support their idiotic invention of requirements.

Note: it’s an INTAREA draft, not transport. 

Joe

> On Nov 10, 2020, at 9:14 AM, Susan Hares <[email-masked]> wrote:
> 
> Joe: 
>  
> From: Idr [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Joseph Touch
> Cc: Brian Trammell; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Last Call; tsv-art
> On Nov 9, 2020, at 1:26 PM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Joe and Brian: 
>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 10 Nov 2020 12:56:51 -0500

Joe:

First of all, I’m sorry to indicate “TSV” instead of “INTAREA”.   Second, I will re-read the draft and determine why my questions were wrong. 

Thank you for pointing out the errors in my questions. 

Cheers,  Sue 

From: Joseph Touch [mailto:[email-masked]] 
Sent: Tuesday, November 10, 2020 12:53 PM
To: Susan Hares
Cc: Brian Trammell; [email-masked]; [email-masked]; Last Call; tsv-art
Subject: Re: [Idr] [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19

Hi, Sue,

Joe

Joe: 

Cheers, Sue 

From: Idr [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Joseph Touch
Sent: Monday, November 9, 2020 4:52 PM
To: Susan Hares
Cc: Brian Trammell;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Last Call; tsv-art
Subject: Re: [Idr] [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19

Hi, Sue,

Joe

On Nov 9, 2020, at 1:26 PM, Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

Joe and Brian: 

Sue 

 

+1

Joe

---

From: Joseph Touch <[email-masked]>
Date: Tue, 10 Nov 2020 10:12:43 -0800

Hi, Sue,

FWIW, my view of the text you have is as follows:

- it should be more clear whether you care about path MTU or receiver MTU (EMTU_R); the former ensures “fate sharing” of bytes within a packet along a path, but the latter is actually the limit of what a link can support. E.g., for IPv6, the former is 1280 and the latter 1500; for IPv4, the former is technically 64 and the latter 576.

- tunnels and layers of tunnels do not necessarily reduce the path MTU at the topmost level, e.g., if they correctly support (as should be required) encapsulating header source fragmentation at the ingress and reassembly at the egress
	a tunnel that does not so support source frag and reassembly MUST already support the IPv4 or IPv6 minimums
	it’s easy to see that X over X requires either source frag/reasy at some layer OR no MTU (e.g., Spacewire)
		IPv6 over IPv6, e.g., requires frag/reassy, but sometimes this can be supported at an intermediate layer, e.g., GRE (as noted in 3.6.3)

The doc already discusses tunnel signaling and why that’s not a solution as well, in sec 4.3.1

Joe

> On Nov 10, 2020, at 9:56 AM, Susan Hares <[email-masked]> wrote:
> 
> Joe:
>  
> On Nov 10, 2020, at 9:14 AM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Joe: 
>  
> -- 
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>