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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 11 July 2016 21:45 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 BEFE912D0BF for <int-area@ietfa.amsl.com>; Mon, 11 Jul 2016 14:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tpFLxeqB3CTc for <int-area@ietfa.amsl.com>; Mon, 11 Jul 2016 14:45:08 -0700 (PDT)
Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 3273912D0B7 for <int-area@ietf.org>; Mon, 11 Jul 2016 14:45:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6BLj7Dg053795; Mon, 11 Jul 2016 14:45:07 -0700
Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6BLj6Gg053785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 14:45:07 -0700
Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 14:45:06 -0700
Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 11 Jul 2016 14:45:06 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt
Thread-Index: AQHR2GRt4KMsEiq3UE+L137uMsNVnaAO8uMQgAB+vYCAA/SlcIAA0H2A//+R3xA=
Date: Mon, 11 Jul 2016 21:45:06 +0000
Message-ID: <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com>
References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> <57840C05.3030605@isi.edu>
In-Reply-To: <57840C05.3030605@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.137.12.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/bwjLoE9STZ3HWVGBRBxZtNv79Ts>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 11 Jul 2016 21:45:11 -0000

Hi Joe,

I was unable to parse most of what you said, but one point that requires
clarification:

> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why
> other methods, e.g., directly querying the egress, may be useful.

That is not true to my understanding. When the original source uses PLPMTUD,
the probes take exactly the same path as the data packets so PLPMTUD works
even if there is multipath.

This is different than for tunnels, because the tunnel ingress is not the source
of the original packets - it is only the source of the encapsulated packets. And,
the ingress may need to encapsulate pacekts produced by many original
sources which may take very different routes due to multipath within the tunnel.

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Monday, July 11, 2016 2:14 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt
> 
> Corrections below as needed...
> 
> On 7/11/2016 10:43 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> > In this second part, I will address some of my concerns with intarea-tunnels:
> >
> > I understand that intarea-tunnels wants to view the tunnel as if it were an
> > ATM link that fragments packets larger than the cell size and no larger than
> > the egress reassembly unit. That being the case, the document would need
> > to say what the cell size is,
> intarea-tunnels allows that to be a property of a tunnel and does not
> mandate it.
> 
> >  and afaict that size should be 1280-ENCAPS
> > (resulting in an encapsulated packet no larger than 1280).
> 
>   For IPv6 in IPv6, the TIMTU (what you call 'cell size', which is
> really the cell payload size, i.e., the native payload of the link) is
> 1280-encaps. The size of "encaps" depends on the configuration if the
> tunnel ingress, e.g., whether it uses IPsec or other IP extension headers.
> 
> That means the unfragmented TTP would need to be smaller than 1240
> (assuming the minimum IPv6 header).
> 
> > I understand the
> > attractiveness of this model, because it makes the tunnel look like a link,
> > but there are several important differences.
> >
> > First, unlike ATM the tunnel may be carried over paths with links that have
> > highly asymmetric MTUs, link bandwidths, and packet loss ratios. That means
> > that (again unlike ATM) one or more fragments in a fragmented packet could
> > be lost resulting in loss of an entire packet which the original source would
> > then have to retransmit. I agree that if the original source is using RFC4821
> > that it would then start sending smaller packets, which is good.
> I assume the Internet link model (e.g., as discussed in RFC3819), which
> assumes that a link is defined by a uniform set of such properties.
> Where this varies, the "least common" values could be used (the smallest
> PMTU). Where that's not desired, it would be more appropriate (and
> sufficient) to model these as separate tunnels.
> 
> > However, sending 1280b fragments over paths that support much larger packets
> > (e.g., 8KB) would be inefficient and would nullify the advantage of setting a larger
> > MTU on the tunnel interface in the first place.
> Tthis is where our two docs disagree. IMO,  PMTU is intended to ensure
> that packets can traverse a net, NOT that the source can find the
> optimal largest such size.
> 
> I.e., IMO PMTU is not about efficiency; it's about reachability.
> 
> That's why we reach different conclusions below.
> 
> > This is why AERO says that only
> > packets up to 1500 bytes in length are fragmented (when necessary), and larger
> > packets should be sent in a single piece.
> >
> > By sending large packets in a single piece, there is no need for the ingress to
> > have to discover the egress' reassembly buffer size. This becomes important
> > when there is one ingress and many egresses such as on an NBMA link.
> 
> The MTU of a tunnel is defined by the ERMTU, not the PMTU, because ERMTU
> packets *can* traverse the tunnel.
> 
> > The document also does not state the circumstances under which fragmentation
> > can be avoided (see: AERO Sections 13.3.1 and 13.3.2). In general, fragmentation
> > is undesirable when the source is capable of reducing the size of the messages
> > it sends. Text such as that appears in AERO sections 13.3.1 and 13.3.2 should
> > be added to intarea-tunnels.
> 
> In all Internet networks, fragmentation is avoided by sending packets
> smaller than the required min MTU.
> 
> There's no part of Internet protocols that are designed to avoid link
> fragementation; only network.
> 
> > The document also talks about outer fragmentation only, and does not talk about
> > tunnel fragmentation (see RFC2764).
> It specifically discusses both inner and outer fragmentation.
> 
> It also discusses inner fragmentation in the context of source
> fragmentation as one of the two key fragmentation algorithms.
> 
> >  Tunnel fragmentation is different than outer
> > fragmentation, and it is possible for both to be employed on the same packet.
> > See: draft-herbert-gue-extensions for an application of tunnel fragmentation.
> 
> The tunnel ingress can fragment at any layer it wants - i.e., if the
> ingress accepts IP and sends them over GUE, it can fragment at GUE or
> the final IP. That's up to the way the link is specified, and
> intarea-tunnels considers that link-layer fragmentation.
> 
> > Finally, I am not sure what you mean by this:
> >
> >    "When ongoing ingress fragmentation and egress reassembly would be
> >    prohibitive or costly, larger MTUs can be supported by design and
> >    confirmed either out-of-band (by design) or in-band (e.g., using
> >    PLPMTUD [RFC4821], as done in SEAL [RFC5320] and AERO [Te16])."
> >
> > By PLPMTUD, do you mean sending an unfragmented large packet to see if it
> > reaches the egress? Or, do you mean sending a *fragmented* large packet to
> > see if it reaches the egress?
> PLPMTUD would involve sending some larger packets.
> 
> Other methods may involve directly querying the egress, e.g., "what is
> your ERMTU?"
> 
> > The former does not work due to multipath, as I
> > explained in a recent list message and (I thought) confirmed by you. The
> > latter could be useful to test the egress' reassembly buffer size no matt
> 
> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why
> other methods, e.g., directly querying the egress, may be useful.
> 
> > er
> > whether there is multipath within the tunnel. Which one did you mean?
> >
> > We agree that fragmentation and reassembly is a necessary consideration for
> > tunnels in the Internet architecture. We are not clear yet on the advantages of
> > sending whole packets vs. fragmented packets for sizes larger than 1500. I
> > believe that operation over tunnels with a single ingress and potentially many
> > egresses (e.g., such as for NBMA) needs more clarification. And, I have stated
> > above a number of omissions in intarea-tunnels that are covered by AERO and
> > should be brought into your document.
> I disagree that any are relevant because they assume the need to
> transfer link payloads larger than are required by either IPv6 links or
> IPv6 endpoints.
> 
> Joe
> 
> 
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:touch@isi.edu]
> >> Sent: Friday, July 08, 2016 1:23 PM
> >> To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf.org
> >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt
> >>
> >> Fred,
> >>
> >> The text in draft-ietf-intarea-tunnels reflects the current IPv4 and
> >> IPv6 transit and endpoint MTU requirements. It also separates the
> >> existing host and gateway fragment processing functions from that of the
> >> tunnel.
> >>
> >> Can you be more specific where you think the algorithms presented are
> >> incorrect? The basis of the text in the current draft was vetted by
> >> several other parties.
> >>
> >> ----
> >>
> >> I don't consider draft-templin-aerolink a useful starting point,
> >> however. The following is a PARTIAL list of why:
> >>
> >> - It imports RFC4459 by reference, which is demonstrably incorrect on
> >> several points (see draft-ietf-intarea-tunnels Sec 5.5.5).
> >>
> >> - It is inconsistent - claiming that Aero links support minimum MTUs of
> >> 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is
> >> "(initially set to the MTU of the underlying link to be used for
> >> tunneling minus ENCAPS)" and endorsing the notion that the path MTU of a
> >> tunnel can be lower than the requirement of IPv6 ("These procedures
> >> apply when the path MTU for this egress is no smaller than (1280+ENCAPS)
> >> bytes -- which, for most Internet paths, cannot be assumed to be larger
> >> than 1280. This completely ignores the requirement that the tunnel
> >> egress be capable of reassembling a 1500 B datagram, so the correct
> >> limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunnels
> >> Sec 4.1).
> >>
> >> - it recommends that the Aero interface send PTB packets (routers, not
> >> interfaces, generate PTBs).
> >>
> >> - it admits packets up to 1500 B without considering that this exceeds
> >> the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoints,
> >> such as the egress, must support reassembling a 1500 B IP datagram, but
> >> this yields a tunnel capacity of 1500-encaps, not 1500).
> >>
> >> Joe
> >>
> >> On 7/8/2016 1:00 PM, Templin, Fred L wrote:
> >>> Hi Joe,
> >>>
> >>> Sorry to say, but I still disagree with most aspects of the text on fragmentation
> >>> and MTU, which are largely the same as what appeared in the previous draft
> >>> version. I will say that we agree on one fact, however, in that fragmentation
> >>> is ultimately unavoidable.
> >>>
> >>> When we discussed this last year, I thought we had established some things
> >>> that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd like to invite
> >>> you and the working group to review that text which IMHO presents a
> >>> better MTU and fragmentation consideration for tunnels.
> >>>
> >>> Thanks - Fred
> >>> fred.l.templin@boeing.com
> >>>
> >>>> -----Original Message-----
> >>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch
> >>>> Sent: Thursday, July 07, 2016 8:29 AM
> >>>> To: int-area@ietf.org
> >>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt
> >>>>
> >>>> Hi, all,
> >>>>
> >>>> This update incorporates all pending changes, notably from detailed
> >>>> reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert,
> >>>> and Tom Herbert.
> >>>>
> >>>> There's still a bit to do - notably to wrangle out what we want to say
> >>>> regarding other RFCs in Section 5. This, and the doc's evolution,
> >>>> suggest that it might be useful to consider shifting the intended track
> >>>> from Informational to BCP or beyond, depending on whether we need to be
> >>>> higher than BCP to "update" some of the problems outlined with
> >>>> standards-track docs (most notably RFC2003).
> >>>>
> >>>> NOTE: A brief summary will be presented by the chairs in Berlin, but I
> >>>> will not be attending. Please use the list as the primary venue for
> >>>> discussion.
> >>>>
> >>>> I am currently hoping we can decide how to proceed on this doc in the
> >>>> next few months so we can either remove or complete any "pending"
> >>>> sections and get to WGLC early this fall.
> >>>>
> >>>> Joe
> >>>>
> >>>> ---------
> >>>>
> >>>> Summary of changes:
> >>>> - now "updates" 4459 (informational too)
> >>>> - revised MTU terminology based on list discussions (all MTUs indicate
> >>>> "link" payload sizes)
> >>>> - revised figures to indicate proximity of ingress/egress "interfaces"
> >>>> to nodes
> >>>> - moved Appendix A to new Section 3.6, as outer/inner fragmentation
> >>>> issue is core
> >>>> - revised Sec 4.2 (was 4.1) to explain why two different frag algs are
> >>>> presented
> >>>>     - one is implicit in all hosts/forwarders, irrespective of link
> >>>> technology
> >>>>     - one is contained "within" the link technology of a tunnel
> >>>> - updated recommendations throughout section 5
> >>>>
> >>>> Summary of additions:
> >>>> - Sec 4.1 on the variety of MTU values
> >>>> - Sec 4.12 on multipoint tunnels
> >>>> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE
> >>>> - Sec 5.5.15 on RTGWG-DT-ENCAP
> >>>> - Security Considerations text on inner/outer tunnel vulnerabilities
> >>>> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4)
> >>>>
> >>>> ----
> >>>>
> >>>> On 7/6/2016 11:28 PM, 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-03.txt
> >>>>> 	Pages           : 47
> >>>>> 	Date            : 2016-07-06
> >>>>>
> >>>>> Abstract:
> >>>>>    This document discusses the role of IP tunnels in the Internet
> >>>>>    architecture, in which IP datagrams are carried as payloads in non-
> >>>>>    link layer protocols. It explains their relationship to existing
> >>>>>    protocol layers and the challenges in supporting IP tunneling based
> >>>>>    on the equivalence of tunnels to links.
> >>>>>
> >>>>>
> >>>>> The IETF datatracker status page for this draft is:
> >>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/
> >>>>>
> >>>>> There's also a htmlized version available at:
> >>>>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03
> >>>>>
> >>>>> A diff from the previous version is available at:
> >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-03
> >>>>>
> >>>>>
> >>>>> 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
> >
>