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

[Joe Touch <[e-mail]>]

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
> [e-mail]
>
>> -----Original Message-----
>> From: Int-area [mailto:[e-mail]] On Behalf Of Joe Touch
>> Sent: Thursday, July 07, 2016 8:29 AM
>> To: [e-mail]
>> 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, [e-mail] 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/int-area
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
>