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

["Templin, Fred L" <[e-mail]>]

Hi Joe,

I will respond to your post in two parts - first, I will respond to your critique
of AERO (see below):

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Friday, July 08, 2016 1:23 PM
> To: Templin, Fred L <[e-mail]>; [e-mail]
> 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:

You know that I have been developing the text in AERO since 2002 (you
know because you have been watching me do it). The AERO text is what
I arrived at when many other approaches failed.

> - It imports RFC4459 by reference, which is demonstrably incorrect on
> several points (see draft-ietf-intarea-tunnels Sec 5.5.5).

Your critique of RFC4459 seems to be based on the assertions you are making
in your document (e.g., egress reassembly size as tunnel MTU). I am saying
that I do not agree with those assertions.

> - 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)

1280+ENCAPS refers to the path MTU *within the tunnel*, and not the
MTU of the tunnel interface. There are two levels of MTUs to consider;
the MTU of the tunnel interface (which must be a minimum of 1280)
and the path MTU within the tunnel interface. The text is consistent
in that way.

> 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).

No, it says that the tunnel egress must be capable of reassembling at
least 1500+ENCAPS and therefore recommends that the egress be
capable of reassembling at least 2KB.

About your 1500-ENACPS, that would leave us in no better condition than
where things stand today. If the tunnel ingress sets an MTU of 1500-ENCAPS,
and if it returns a PTB listing an MTU less than 1500, the PTB could be lost and
the original source would never learn that there was a path MTU restriction.
That is whey AERO enforces a minimum MTU of 1500 bytes for situations
where the original source might not receive PTBs.

> - it recommends that the Aero interface send PTB packets (routers, not
> interfaces, generate PTBs).

RFC1981(bis) says:

  "Note that Path MTU Discovery must be performed even in cases where a
   node "thinks" a destination is attached to the same link as itself."

and:

   "If any of the packets sent on that path are too large to be forwarded
   by some node (regardless of whether it decrements the Hop Limit)
   along the path, that node will discard them and return ICMPv6 Packet
   Too Big messages [ICMPv6]."

Forwarding nodes that do not decrement the hop count are exactly what
happens within the AERO interface.

> - 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).

Just as tunnels over IPv4 assume a larger reassembly unit than the RFC1122
guarantee of 576B, we are now asking the egress to set a reassembly unit
of at least 1500+ENCAPS. Setting a minimum reassembly unit that exceeds
the IPv6 1500  should be in scope for this document.

Remember - we are trying to get away from tunnels that set an MTU
smaller than 1500 so that hosts that send packets that are no larger
than 1500 will not get black-holed.

Thanks - Fred
[e-mail]

> 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
> >
>