Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 28 March 2017 16:36 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9593A128D40 for <int-area@ietfa.amsl.com>; Tue, 28 Mar 2017 09:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pllvglVVmLM9 for <int-area@ietfa.amsl.com>; Tue, 28 Mar 2017 09:36:29 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195C212751F for <int-area@ietf.org>; Tue, 28 Mar 2017 09:36:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2SGaR41033982; Tue, 28 Mar 2017 09:36:27 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2SGaJtZ033793 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 28 Mar 2017 09:36:19 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 28 Mar 2017 09:36:18 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 28 Mar 2017 09:36:18 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>
CC: "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslg
Date: Tue, 28 Mar 2017 16:36:17 +0000
Message-ID: <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com>
References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <f5ab0422-fd49-9082-147b-8312e974de7e@isi.edu>
In-Reply-To: <f5ab0422-fd49-9082-147b-8312e974de7e@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/PpRVXV1f5hQjcK9hEUyEMwo8QE0>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 16:36:32 -0000
Here are my comments for this draft. Mostly editorial, but some substantial. I also noticed several indications that further work was needed in some sections. Will those sections be worked before publication? Thanks - Fred fred.l.templin@boeing.com 1) P. 5, change "in which packet sizes ... mismatch" to "in which packet size ... mismatches" 2) P. 8, definition of Path MTU, the trailing phrase "(if supported) seems awkward and does not seem necessary. Can this be dropped? 3) Section 3.2, "Tis MTU" should be "This MTU". 4) Section 3.4, "egress receives packets to decapsulates". Change "decapsulates" to "decapsulate". 5) Section 4.1, "Tunneling uses encapsulation uses a non-link protocol" looks strange. Reword to make a coherent sentence. 6) Section 4.1.4, "Although fragmentation is somewhat rare in the current Internet at large, but it can be" - eliminate "but". 7) Section 4.2.1, first paragraph after Figure 10, "The minimum EMTU_R (c) is 1500 bytes", should be: "The minimum EMTU_R (d) is 1500 bytes". 8) Section 4.2.1, third paragraph after Figure 10, "The tunnel EMTU_R is EMFS_R minus the link (encapsulation) headers includes the encapsulation headers of the link layer." - I tried, but could not parse this sentence. 9) Section 4.2.1, third paragraph after Figure 10, should cite MFS, Path MFS and EMFS_R by including their letter designators (i.e., (h), (i), (j)) as was done in the previous two paragraphs. 10) Section 4.2.1, bulleted list toward bottom of section, tunnel "atom" is a very strange word to me. Tunnel "cell"? 11) Section 4.2.2, second paragraph after Figure 12, "Transit packets larger than 1460-EHsize will be dropped" does not match with two sentences earlier where it says that the tunnel path MTU will be *at least* 1500 - (40 + EHsize). It should just say "Transit packets larger than the tunnel MTU will be dropped". 12) Section 4.2.2, paragraph beginning "An IPv6 tunnel supports IPv6 transit only if EHsize is 180 bytes or less". I know what this paragraph is trying to say, but the 180 only pertains to cases where the EMTU_R is constrained to the IPv6 minimum of 1500. When EMTU_R is larger, EHsize could also be larger. In fact, I think the document would do well to simply omit this paragraph because the relationship between EHsize and EMTU_R is already established in the previous paragraphs. 13) Section 4.2.2, final sentence is incorrect. RFC4821-style MTU probing cannot be used by tunnels due to ECMP because the probe packets may take a different path than the data packets. That is why AERO no longer uses RFC4821 probing. 14) Section 4.2.2, should include discussion of how common tunnel specs regard EMTU_R and the tunnel atom (cell) size. Namely, many common specs assume larger EMTU_R and tunnel cell sizes than are guaranteed by RFC1122 and RFC2460. That means that these tunnel specs are relying on operational assurances of larger values than the IPv4 and IPv6 minimums. Since they are already published as standards, this document needs to explain how they are able to operate without fragmentation. 15) Section 4.2.3, second paragraph "too bit to for" should be "too big for". 16) Section 4.2.3, final paragraph, "message too big" should be "packet too big". 17) Section 4.2.3 cites RFC4821, but PLPMTUD cannot be used by tunnels due to ECMP. The tunnel ingress is only the source of the tunnel packets; it is not the source of the transit packets. Since the transit packets of many different flows may be subject to the same tunnel packet encapsulation, the RFC4821 probes could travel over very different paths than the ordinary data packets and could experience very different path MTUs over those paths. 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define an NBMA multipoint tunnel framework that has been around a lot longer than the other examples cited. 19) Section 4.3.3, third paragraph, I thought it was said earlier that all ingress/egress pairs must support the same MTU. I thought we agreed earlier on that that multi-MTU subnets don't work. So, I think it should say that all ingress pairs MUST support a uniform MTU. 20) Section 4.3.3, fourth paragraph, "A multipoint tunnel MUST have support for broadcast and multicast" - I think this would be better as a "SHOULD". RFC2529 and AERO support multicast, but RFC5214 does not yet it is widely deployed. 21) Section 4.3.4 second paragraph illustrates why RFC4821 cannot be used over tunnels. 22) Section 5.1, second sub-bullet under "Tunnel endpoints are network interfaces", change: "they not generate" to "they do not generate" 23) Section 5.1, first sub-bullet under "Tunnels must obey core IP requirements", Are you meaning to talk about IPv4 DF=1? 24) Appendix A.2 - this section should say something about implications for ECMP when a multi-encapsulation like this includes multiple packets that, if transmitted individually, would take different paths within the tunnel. Also, in the figure the insertion of the block labeled "iHa | iDa" should show up as "iHa | iDa" within the packed packet (it currently shows up as "iHa | iHa". > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Monday, March 27, 2017 8:39 AM > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt > > Hi, all, > > This update catches some typos that are important for understanding the > terminology changes. > > Joe > > > On 3/27/2017 8:34 AM, internet-drafts@ietf.org 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-05.txt > > Pages : 51 > > Date : 2017-03-27 > > > > Abstract: > > 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: > > https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-05 > > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-05 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-05 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
- [Int-area] I-D Action: draft-ietf-intarea-tunnels… internet-drafts
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-tun… Templin, Fred L