[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Tunnel MTU
Hi Mark,
> -----Original Message-----
> From: Mark Townsley [mailto:townsley@cisco.com]
> Sent: Tuesday, July 28, 2009 12:14 PM
> To: Templin, Fred L
> Cc: IPv6 Operations
> Subject: Re: Tunnel MTU
>
> Templin, Fred L wrote:
> > Mark,
> >
> >
> >> -----Original Message-----
> >> From: Mark Townsley [mailto:townsley@cisco.com]
> >> Sent: Tuesday, July 28, 2009 10:44 AM
> >> To: Templin, Fred L
> >> Cc: IPv6 Operations
> >> Subject: Re: Tunnel MTU
> >>
> >>
> >> Thanks for keeping us on our toes Fred!
> >>
> >> I'd like to clarify of course that some of the MTU issues we
discussed
> >> were not specific to tunneling, but to mismatched MTUs on a home
LAN
> >>
> > vs.
> >
> >> WAN interface in general. The extra 20 bytes of a 6rd or 6to4
> >> encapsulation isn't significant when trying to solve support of 9K
> >>
> > jumbo
> >
> >> frames and standard 1500 byte ethernet MTUs in the same network.
> >>
> >
> > Two issues here. First, if the home link has a 9KB MTU
> > and the CPE advertises something like 1480, all nodes
> > on the home link will be stuck using a 1480 MTU even
> > for communications that never leave the link. At least
> > that's how it is in current IPv6 implementations.
> >
> > Secondly, if the home network has multiple links (connected
> > by routers), the links that are deep inside of the home
> > network will not see the CPE router's MTU advertisement
> > and will continue using the native link size (e.g., 1500
> > bytes). Their 1500 packets will then of course be dropped
> > by the CPE router and an annoying ICMP PTB sent back to
> > trigger an even more annoying retransmission.
> >
> These two problems are present with or without tunneling. Taking a
1500
> MTU down to 1480 isn't exacerbating the fundamental problem here.
1480
> & 9000 vs. 1500 & 9000 is effectively the same problem space.
Well, with SEAL you can get the 9KB's through even if there
is a 1500, 1480 or even a 576 in the middle. But see below:
> >> Tunneling does affect MTU, no doubt. I'll point out that with 6rd,
the
> >> deployment space of the tunnel is limited, making it dramatically
> >>
> > easier
> >
> >> to "tune" than with 6to4. Unlike SEAL, this is still essentially an
> >> operator tweaked value in the current deployment model.
> >>
> >
> > As I said in the meeting, the tunnel gives you a
> > configuration knob with 1280 at the "safe" extreme
> > and 1480 at the "living dangerous" extreme (unless
> > of course you know that *all* links in the ISP network
> > configure a larger MTU).
> Yes, this is a very good illustration, Fred. This is effectively what
we
> are offering with 6rd - a knob.
Agreed.
> > Another concern is what to
> > do about a misconfigured link somewhere in the ISP
> > network (e.g., it sets an MTU of 900 when it meant
> > to set 9KB). SEAL will ride over that without loss
> > and will even help identify the degenerate link so
> > it can be fixed. Without SEAL, setting a static MTU
> > even as small as 1280 causes undetected fragmentation
> > that can lead to severe problems especially when we
> > have anycast in the mix.
> >
> Isn't this a general advantage of SEAL? That is, tunnels aside, SEAL
> aims to solve MTU mismatch problems. Tunnels by their definition have
> the *potential* to create an MTU mismatch, but the scope of SEAL is
> beyond just tunneling.
SEAL can be used end-to-end, yes.
> > To go one step further, let's say we have home network
> > A and home network B with 9KB links behind CPE routers
> > running 6RD over an ISP network that is known to include
> > 1500 links. With SEAL, nodes in home network A can send
> > 9KB IPv6 packets to nodes in home network B *even though
> > the ISP network only supports 1500*. For that matter,
> > SEAL can also support IPv6 jumbograms (>64KB) over the
> > ISP network for those home users that truly want to push
> > the limits.
> >
> Again - all neat stuff, but tunneling is but one case where MTUs are
> mismatched. In most of the cases you list here, the mismatch is more
> inherent in the link capabilities or configuration of those links by
an SP.
>
> If your point is to identify SEAL as potentially useful in cases where
> tunnels are used, I think you have succeeded. But, I do see that as a
> separable issue from 6rd itself.... If I heard you correctly at the
mic
> today, you do as well, which I think is the right way to tackle each
> problem.
Correct - I am not suggesting any of this for the "base"
6rd document at this time. I do however think the base
document would benefit from a short 2-3 sentence paragraph
noting the limitations.
I am however seeing the potential for a follow-on document
that examines more advanced scenarios, e.g., for ISP
networks that want to partition themselves internally.
I have in mind something of a "6rd++" that might better
serve those uses.
Fred
fred.l.templin@boeing.com
>
> - Mark
>
> > Fred
> > fred.l.templin@boeing.com
> >
> >
> >> - Mark
> >>
> >> Templin, Fred L wrote:
> >>
> >>> Hi,
> >>>
> >>> Tunnel MTU issues came up in both the 6rd and CPE router
> >>> discussions today. As near as I can tell, the issues are
> >>> not going to go away and will keep coming up over and
> >>> over again the more we talk about tunneling.
> >>>
> >>> SEAL is proposal that has a real chance of cleaning up
> >>> the issues once and for all. I will be briefing the
> >>> updates to the document at the intarea meeting tomorrow,
> >>> but in the meantime the draft is here:
> >>>
> >>> http://tools.ietf.org/html/draft-templin-intarea-seal-05
> >>>
> >>> Comments or questions welcome,
> >>>
> >>> Fred
> >>> fred.l.templin@boeing.com
> >>>
> >>>
> >>>
> >>>
> >
> >
> >