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