Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, February 18, 2014 10:53 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:44 AM, Templin, Fred L wrote: > > 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? > > Yes; it already is supposed to be one-stop, generic text for all tunnel > issues, and has a section on MTU issues already. Can you let us know > what part of that needs to be fixed?
Sure, I will take a crack at this. > >> 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/ > > The generic description should explain how and why the rules should > vary. In that case, then specifics do belong in specific tunnel specs. Yes, there will still be a place for specific tunnel specs, but with heavy emphasis on the generic. The key is in the placement of the tunnel egress and ingress in determining the specific adaptations of the generic text to apply. > > 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? > > Yes, but again that's already the purpose of the Intarea tunnel doc, > which already has a lot of different discussions like this (ICMP signal > relaying, MTU, etc.). Do we have agreement that the Intarea tunnel doc would be revived then (looks like it has been expired for a while now). Thanks - Fred [email protected] > Joe > > > > > > > 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
