Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip

On 5/5/2015 10:18 AM, Dave Dolson wrote:
> Joe,
> I think this discussion is about fragmenting the outer IP packet.

That's feasible for IPv6, but extremely limiting for IPv4 because of the
limited ID field size (it would rate-limit the tunnel significantly).

> There is a 3rd choice: to fragment the inner datagram,

That is not valid for IPv6 or IPv6 DF=1, so unless you support only IPv4
DF=0 packets, it won't work.

> and/or use ICMP "datagram is too big" messages to facilitate
> PMTU discovery of the tunnel.

That won't work for several reasons:
	- ICMPs are often blocked
	- ICMP might not return enough of the nested headers
	- ICMP cannot validly say "1280 is too big" for IPv6
	(which it would need to do if the path supported only
	1280, because there wouldn't be space for the additional
	IP header)

> This certainly seems to have been the intent, when one reads about
> the IPv4 DF flag. (And IPv6 always requires DF).

See above; while the DF issue might be useful in some contexts, it
doesn't magically get around the need to fragment in ways that are not
supported by the inner header.

Joe

> -----Original Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Tuesday, May 05, 2015 12:33 PM
> To: Xuxiaohu; Donald Eastlake; trill@ietf.org
> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org
> Subject: Re: [sfc] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
> 
> 
> 
> On 5/4/2015 7:23 PM, Xuxiaohu wrote:
>> In a word, IP-in-UDP is just intended for those network environments
>> where fragmentation on the tunnel layer and strong checksums are not
>> desired.
> 
> That's insufficient. They are only applicable where fragmentation and a
> strong checksum are not *needed*.
> 
> Once you run IP in IP (IP in UDP in IP qualifies as this), you have only
> two choices:
> 
> 	- support fragmentation
> 
> 	- use in networks that are engineered so that
> 	fragmentation is never needed
> 
> As to the strong checksum, similarly you have to either support one or
> deploy the result where that checksum isn't needed - either because you
> know that all apps will have strong enough checksums of their own or
> because you know enough about the kinds of errors that will occur that
> strong checksums aren't needed.
> 
> But the key there is to define a use case where these properties are
> true AND to limit the document solution to uses in those case ONLY.
> 
>> For those network environments where fragmentation on the
>> tunnel layer and stronger checksums are required, GUE should be
>> considered instead.
> 
> Agreed.
> 
> Joe
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
> 