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, and afaict that size should be 1280-ENCAPS (resulting in an encapsulated packet no larger than 1280). 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. 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. 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 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. The document also talks about outer fragmentation only, and does not talk about tunnel fragmentation (see RFC2764). 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. 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? 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 matter 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. Thanks - Fred [email protected] > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Friday, July 08, 2016 1:23 PM > To: Templin, Fred L <[email protected]>; [email protected] > 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 > > [email protected] > > > >> -----Original Message----- > >> From: Int-area [mailto:[email protected]] On Behalf Of Joe Touch > >> Sent: Thursday, July 07, 2016 8:29 AM > >> To: [email protected] > >> 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, [email protected] 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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/int-area > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
