Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, June 25, 2013 2:38 PM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt > > Hi, Fred, > > ... > >> A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation > is. > >> > >> I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}. > >> Beyond that it *cannot* reassemble. > > > > I have a slightly different view, but one that still involves > > fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU > > of 1280 bytes. > > In what it sends over IP (i.e., in the chunks it uses to transit from > ingress to egress). There's no reason to impose that limit on what it > receives at the ingress.
What I am suggesting is that the tunnel ingress sets an indefinite MTU, meaning that all packets are admitted into the tunnel regardless of their size. But, see more below... > > But, to uphold the de facto Internet cell size of > > 1500 bytes we should extend this up to 1500. So, if the MTU within > > the tunnel is unknown and/or unknowable, then the ingress MUST use > > fragmentation to make sure that packets no larger than 1500 bytes > > get through - the egress then gets to reassemble. > > This is an artificial limit that is unnecessary. What I am after is a fragmentation threshold designed to set an upper bound on the amount the tunnel egress will have to reassemble. This also happens to be the size of packets that MUST make it through the tunnel. IPv6 says that this value must be set to 1280 at a minimum. I am saying that it should be bumped up to 1500 to mirror the minimum MTU used on the vast majority of links in the Internet today. But, see more below... > IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can* > transit packets arriving at the ingress that are 65535-IP-GRE, why > should it do otherwise? What I am saying is that all packets are admitted into the tunnel regardless of their size, but the tunnel will use fragmentation only for those packets that MUST make it through to the other side, i.e., all packets that are no larger than 1500 bytes. This means that the tunnel egress need only configure a reassembly buffer size of 1500 bytes plus the tunnel overhead. Packets larger than 1500 bytes will still make it through the tunnel (in one piece) if the MTU within the tunnel can accommodate that size. But, the most the ingress will ever ask the egress to reassemble is 1500 (plus overhead). > (yes, it *can* be configured lower if desired, just as with any other > link, but there's no reason to assume 'lower than maximum' as a > default) > > > Packets larger than 1500 can be admitted into the tunnel unfragmented > > and allowed to sink or swim on their own. > > Whether and how much GRE fragments what it receives at an ingress ought > to be determined by its understanding of its own ingress-egress MTU > capability. However, those fragments are not directly related to what > the tunnel can transit *because* the ingress can fragment and the > egress > can reassemble. Right. The egress has to reassemble whatever the ingress fragments. What I am saying is that the ingress put a conservative upper bound on the amount it will ever ask the egress to reassemble. > Acting like the ingress and egress can't participate in frag/reassembly > of the outer packet introduces an artificial limit to GRE tunnels. If > that's what you want to do - or what has already been done - that's > fine, but *that* is what is suboptimal. No, I fully agree that *some* fragmentation and reassembly is necessary. I'm just saying that the ingress should set a limit on the most it would ever ask the egress to reassemble. But, that does *not* put an artificial limit on the tunnel MTU. > > The ingress may or may not > > get ICMP PTBs if one of these is dropped, but the source should be > > using RFC4821 when it sends packets larger than 1500 bytes anyway, > > so loss of PTBs should not affect the hosts. > > Agreed on that point, but not the 1500-byte transit limit. Please reread the algorithm I proposed, Joe. What I am suggesting is an "infinite" tunnel ingress MTU - not a 1500 byte MTU. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
