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

Joseph Touch <> Tue, 10 November 2020 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EAA53A0DB2; Tue, 10 Nov 2020 09:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sdtn361oYTnX; Tue, 10 Nov 2020 09:52:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECF463A0DB5; Tue, 10 Nov 2020 09:52:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4PJ3ubf5PJoxjI55pthq8iLFyBC6+yEC8rRie4KeFHc=; b=qjCqKFeEhdQN/vPswBMoB+2vf QJOakkpYOraMR6PZcYwarZfGH75xzHP1J6LDxFbnTwr67m7PrXdaVwTkLqQTzcaCxMvcodnCLoZTs EvLg02SJkE5U5qeDXTwBJSaDhlwA17G1FAnIY216weW00TATPfPhiQ/RaZ9zZCDgvdojPUOKEnYGq zUGpyD58duWT3PiNTbG8HyX+7WYI75hcxJNegHpY4FGm2EHQX/TzmArCeM+ueQt6sZPBvP3Da9UAy Ti04jaehg0/a0SwW1ecH01LZIcyMCAzRWer6ciXy7lA8N8ZHQhl0D+g+OGGRvxJWsIlpAZgtz3xI+ 5UTWOtO3g==;
Received: from ([]:56690 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1kcXox-002CfP-Vk; Tue, 10 Nov 2020 12:52:49 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_5CA76B79-01DC-44AF-990F-0DDAD2E11D96"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Joseph Touch <>
In-Reply-To: <026801d6b784$f4062da0$dc1288e0$>
Date: Tue, 10 Nov 2020 09:52:42 -0800
Cc: Brian Trammell <>,,, Last Call <>, tsv-art <>
Message-Id: <>
References: <> <> <007f01d6b6df$09da44f0$1d8eced0$> <> <026801d6b784$f4062da0$dc1288e0$>
To: Susan Hares <>
X-Mailer: Apple Mail (2.3608.
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Tsv-art] [Idr] [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2020 17:52:52 -0000

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. 


> On Nov 10, 2020, at 9:14 AM, Susan Hares <> wrote:
> 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 [ <>] On Behalf Of Joseph Touch
> Sent: Monday, November 9, 2020 4:52 PM
> To: Susan Hares
> Cc: Brian Trammell; <>; <>; Last Call; tsv-art
> Subject: Re: [Idr] [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-idr-tunnel-encaps-19
> 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 < <>> wrote:
> 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 [ <>] 
> Sent: Thursday, October 15, 2020 9:12 PM
> To: Brian Trammell
> Cc: tsv-art; Last Call; <>; <>
> 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 < <>> 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
> _______________________________________________
> Tsv-art mailing list
> <>
> <>