Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt

"Black, David" <> Mon, 22 May 2017 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 475CD12EAFF for <>; Mon, 22 May 2017 08:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=p6FvWSKl; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=gVBmJ6xp
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MCG8cYUZPH7q for <>; Mon, 22 May 2017 08:56:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA1BC12EB07 for <>; Mon, 22 May 2017 08:56:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=smtpout; t=1495468573; x=1527004573; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5GKOo317bRnjyOlqgEKWviRb830sC3PliIX538ZEbdc=; b=p6FvWSKlp4QbMHe+93N43fQg13lW4cLmXF/oY8aQwBRhbOIMi3pnDVSH hjXBFSKo8Lp8PCaGLV0bfeHmOZwBwkKHNqn+gVHfuFOlwaeFCg+9Hc48p 1eIqEf8bXwczFxjKiWHLFqAl5gdLE9X9UhLp1DqdzdnL7nqW8IXOcl835 Q=;
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2017 10:56:13 -0500
From: "Black, David" <>
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2017 21:55:28 +0600
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v4MFu9sA012556 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 11:56:11 -0400
X-DKIM: OpenDKIM Filter v2.4.3 v4MFu9sA012556
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1495468571; bh=yBDIcXLsWYzHrVx+ajNaF39lFyQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=gVBmJ6xpL5QyoESecRtxyNsyb5CMifOzFI+6J8THfQTXmfrZLaRbrbvJ/g0t5BzQd hLPQ1OAS8FNT3xB7eKJx8lctgy8YsHWEcczN8fZrs0mvzRW3sDg4caeyTmniJRAA6+ hfcyF+geyLCBceDoTifcvq7jXnOL5mYuu0S/l/X8=
X-DKIM: OpenDKIM Filter v2.4.3 v4MFu9sA012556
Received: from ( []) by (RSA Interceptor); Mon, 22 May 2017 11:54:01 -0400
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v4MFu2CY016860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 22 May 2017 11:56:02 -0400
Received: from ([fe80::849f:5da2:11b:4385]) by ([]) with mapi id 14.03.0266.001; Mon, 22 May 2017 11:56:02 -0400
To: Joe Touch <>, "" <>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt
Thread-Index: AQHSz1SG1cQ2zACXBUueBYQ1qtYIT6H5U6iAgAdvfID//8TwUA==
Date: Mon, 22 May 2017 15:56:02 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FA9793AMX307CL04corpem_"
MIME-Version: 1.0
X-RSA-Classifications: public
Archived-At: <>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 May 2017 15:56:16 -0000

+1 – I concur with Fred that this draft should become a BCP.  The concept of a tunnel as a link is fundamental and should be a foundational principle for how tunnels are designed/specified.

Thanks, --David

From: Int-area [] On Behalf Of Templin, Fred L
Sent: Monday, May 22, 2017 11:24 AM
To: Joe Touch <>du>;
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt

Hi Joe,

I read the whole document, and I think is ready for advancement in its current form
modulo the Informational -> BCP decision. I support changing the document track
from Informational to BCP, with the understanding that more work will be needed
in Section 5 if that would be the case. Thanks for this work.


From: Int-area [] On Behalf Of Joe Touch
Sent: Wednesday, May 17, 2017 2:51 PM
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt

Hi, all,

A new version of intarea-tunnels has been posted, as noted below.

At this point, I would like to ask the chairs to start a WG call to consider revising the document track, as per below.

Some history:

This document began as a set of discussions at IETF 72 in Philadelphia (2008), where a few ADs approached us to try to integrate a number of emerging tunnel efforts, with the assumption of simply integrating them. The result was an attempt to simply organize the landscape at the time.

We started that landscape as an INTAREA WG informational doc in March 2010. It took five years of discussions, both on this list and in other WGs, to realize we needed to start by explaining our understanding of the concept of a tunnel as a link (issues in 2015). At that point we realized that many existing and emerging tunnels were inconsistent with each other and with existing requirements.

We came up with an approach which we believe is both correct and consistent with existing core Internet requirements, and highlighted where it differs from current tunnels (standards track, informational, or otherwise) in Section 5. At this point, we believe the core of this document is both stable and represents not only a clear view of tunnels as an architectural component of the Internet, but also represents the current best practices regarding the design and use of tunnels.

Our request:

As a result, we'd like to ask the chairs to initiate a call to change the track of this document from Informational to BCP.

The result of this decision will impact how Section 5 is resolved. If this document becomes a BCP, that section will be fleshed out for WG consensus. If this document remains Informational, then the recommendations in Section 5 might not be appropriate, and will likely need to be omitted in whole or part.


Summary of 06 changes:

    - updated ECMP discussion

    - updated multipoint discussion

    - updated terminology (atom -> atomic packet)

    - revised Fig 12 and Fig 13 algorithms (it wasn't clear that this was outer fragmentation)


On 5/17/2017 2:28 PM,<> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Internet Area Working Group of the IETF.

        Title           : IP Tunnels in the Internet Architecture

        Authors         : Joe Touch

                          Mark Townsley

 Filename        : draft-ietf-intarea-tunnels-06.txt

 Pages           : 52

 Date            : 2017-05-17


   This document discusses the role of IP tunnels in the Internet

   architecture. An IP tunnel transits IP datagrams as payloads in non-

   link layer protocols. This document explains the relationship of IP

   tunnels to existing protocol layers and the challenges in supporting

   IP tunneling, based on the equivalence of tunnels to links. The

   implications of this document are used to derive recommendations that

   update MTU and fragment issues in RFC 4459.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:


Int-area mailing list<>