Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, February 18, 2014 10:29 AM > To: Templin, Fred L > Cc: Ronald Bonica; [email protected] > Subject: Re: [Int-area] FW: New Version Notification for > draft-bonica-intarea-gre-mtu-04.txt > > > > On 2/18/2014 10:22 AM, Templin, Fred L wrote: > > Hi Joe, > > > > I can see that I am going to have to write a draft on generic tunnel > > fragmentation. > > That's already a section in the tunnel draft that has been a WG doc: > > http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00#section-3.2 > > That doc has languished for lack of feedback, but IMO that's the place > to put all one-stop information on tunnels that transit IP packets.
I can articulate one-stop generic text for tunnel fragmentation. Are you suggesting reviving the above document? > I do agree that the current GRE doc could be more clear on this issue, > but I don't think a new, separate doc on this is needed. Each tunnel type can certainly articulate its own fragmentation scheme if it wants to - I have already done that for 6rd and AERO: https://datatracker.ietf.org/doc/draft-foo-v6ops-6rdmtu/ https://datatracker.ietf.org/doc/draft-templin-aerolink/ But, would be better if the individual docs could point to a one-stop generic text and then just give 1-2 sentences on their specific adaptation of the generic text. Would that work for you? Thanks - Fred [email protected] > Joe > > > It will be based on my e-mail from two messages ago. > > I have already written drafts on 6rd tunnel fragmentation and AERO > > tunnel fragmentation, and they are already consistent with the to- > > be-written draft on generic tunnel fragmentation. Your draft on GRE > > fragmentation can then also cite the generic tunnel fragmentation doc. > > > > Thanks - Fred > > [email protected] > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Tuesday, February 18, 2014 10:09 AM > >> To: Templin, Fred L > >> Cc: Ronald Bonica; [email protected] > >> Subject: Re: [Int-area] FW: New Version Notification for > >> draft-bonica-intarea-gre-mtu-04.txt > >> > >> > >> > >> On 2/18/2014 9:27 AM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>> You seem to be talking past me - maybe it was because I wrote too much. > >>> The fragmentation story for tunnels is very simple as follows: > >> > >> Yes, IMO they are, and here's mine: > >> > >> - if a tunnel CAN transit a packet, it MUST try > >> > >> i.e., the MTU of a tunnel that uses IPv6 encapsulation > >> is 65535 - encapsulation headers > >> > >> - if a tunnel CANNOT transit a packet, it rejects it > >> > >> i.e., anything larger than "65535 - encap headers" > >> > >> Everything else mistakes MSS (maximum) for PSS (preferred). Preferred is > >> the min of the MSS's. An IPv6 tunnel limits MSS only insofar as packets > >> larger than 65535-headers cannot traverse it. > >> > >> So... > >> > >>> 1) IPv6 has a minimum MTU of 1280 bytes. So, packets that are no larger > >>> than this size MUST be accommodated even if a small amount of > >>> fragmentation is necessary. IPv4 has a much smaller minMTU, but > >>> IMHO tunnels SHOULD behave as if the IPv4 minMTU is also 1280. > >> > >> An IPv6 tunnel is a link to the IPv6 protocol. IPv6 requires that the > >> smallest MTU of all links must be no less than 1280. So agreed. > >> > >>> 2) Packets larger than 1500 bytes (with the exception of IPv4 packets > >>> with DF=0) should be allowed to sink or swim on their own. Tunnels > >>> therefore MUST NOT use fragmentation for packets larger than 1500. > >> > >> Completely disagree. The max size of the payload of GRE in IPv6 is much > >> larger than 1500. > >> > >> You're trying to do something at the tunnel layer that the path is > >> supposed to be in control of. > >> > >>> 3) Packets larger than 1280 but no larger than 1500 are in a "gray area" > >>> where the way the tunnel accommodates them depends on the specific > >>> tunnel orientation. In some cases the tunnel should send as a whole > >>> packet. In others, it should drop and send a PTB. In still others, > >>> it should fragment. The cases are easy to articulate. > >> > >> There is no grey area. Until the max payload of an IPv6 packet is > >> decreased, there's simply no justification to do other than the above. > >> > >>> That is really all there is to it. What is important to realize is > >>> that case 3) needs to be architected according to the specific tunnel > >>> orientation - there is no generic one-size-fits-all rule that can be > >>> applied to all tunnels in all orientations. > >> > >> First, if rules depend on orientations, then there would be no rule for > >> tunnels at all. You cannot specify the requirements of a tunnel if it > >> depends on network placement - that rule does not exist for any other > >> Internet component (excepting only endpoint vs. network, but that's > >> function, not just placement). > >> > >> Second, there is a rule. See above. > >> > >> Joe > >> > >> > >>> > >>> Thanks - Fred > >>> [email protected] > >>> > >>> > >>>> -----Original Message----- > >>>> From: Joe Touch [mailto:[email protected]] > >>>> Sent: Tuesday, February 18, 2014 8:47 AM > >>>> To: Templin, Fred L > >>>> Cc: Ronald Bonica; [email protected] > >>>> Subject: Re: [Int-area] FW: New Version Notification for > >>>> draft-bonica-intarea-gre-mtu-04.txt > >>>> > >>>> Hi, Fred, > >>>> > >>>> On Feb 17, 2014, at 10:51 AM, Templin, Fred L > >>>> <[email protected]> wrote: > >>>> > >>>>> Hi Ron, > >>>>> > >>>>> The document needs to talk about packet sizes for IP payload packets. > >>>> > >>>> Yes, and I'm hoping we can add additional detail. > >>>> > >>>> Here's my view: > >>>> > >>>> -- path MTU is based on the min of the largest packet each link in the > >>>> path can support > >>>> > >>>> -- links often transit packets larger than their native size, e.g., > >>>> ATM's MTU is 9K, not 48 bytes > >>>> > >>>> -- links do have a native transit size, though > >>>> > >>>> So there ought to be two very different concepts > >>>> > >>>> - MTU (maximum) > >>>> > >>>> - PTU (preferred) > >>>> > >>>> IMO, much of the confusion about how MTUs are handled by tunnels is > >>>> based on confusing MTU to > mean > >>>> PTU. > >>>> > >>>> I.e., > >>>> > >>>> - a tunnel has a PTU based on avoiding ingress fragmentation > >>>> and egress reassemly > >>>> > >>>> - a tunnel as a MTU, which is the MTU of the path of the tunnel > >>>> minus the headers it adds at the ingress > >>>> > >>>>> For IP payload packets no larger than MINMTU bytes, the GRE tunnel > >>>>> MUST accommodate the packet even if a small amount of fragmentation > >>>>> is necessary. (Here, the mandatory MINMTU for IPv6 is 1280 and the > >>>>> recommended MINMTU for IPv4 is also 1280.) > >>>> > >>>> This artificially limits tunnel MTU based on trying to support a > >>>> perceived PTU, but doesn't match > >> PTU. > >>>> > >>>>> Beyond MINMTU, there needs to be a balance between avoiding path > >>>>> MTU related black holes for the source and avoiding excessive > >>>>> fragmentation at the GRE tunnel egress. > >>>> > >>>> If we really want to accomplish that, we need to flesh out the > >>>> difference between MTU and PTU and > >>>> teach our apps to focus on PTU, ala a new PLPTUD (vs. current PLMTUD). > >>>> > >>>> I don't think we should be guessing this at the time we specify the > >>>> tunnel, because the approach > >>>> varies based on what's transited (real IP packets or some other sort of > >>>> encapsulation, e.g., > IPsec > >> in > >>>> UDP). > >>>> > >>>> > >>>>> This balance is situation > >>>>> dependent. For example, if the GRE tunnel ingress is located close > >>>>> to the source, it should be reasonable to expect that the source > >>>>> would be able to receive any ICMP PTB messages sent by the ingress. > >>>> > >>>> Tunnels transit packets; they're not connected to sources or > >>>> destinations. So are you proposing > >> that a > >>>> tunnel should now try to discover the length of the path in each > >>>> direction and handle different > >>>> addresses differently? IMO, that's worse than reassembly. > >>>> > >>>>> Or, if the GRE tunnel egress is located close to the destination, > >>>>> it should be reasonable to expect that the egress can perform a > >>>>> small amount of reassembly. > >>>> > >>>> Same problem, and worse- do you expect vendors to sell different tunnel > >>>> engines based on intended > >>>> traffic patterns? > >>>> > >>>> ---- > >>>> > >>>> In conclusion, I would urge this document to focus on MTU as the goal, > >>>> at which point the only > >> packets > >>>> that ought to be dropped at the ingress ought to be those that cannot be > >>>> encapsulated with > another > >>>> IPv4 header, i.e., that exceed the *MAXIMUM* payload size. > >>>> > >>>> If we want to tune for preferred path size, we need to extend PLMTUD for > >>>> that purpose. > >>>> > >>>> Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
