> On Mar 8, 2019, at 10:01 AM, Tom Herbert <[email protected]> wrote: > > On Fri, Mar 8, 2019 at 9:42 AM Joe Touch <[email protected]> wrote: >> >> >> On 3/8/2019 9:33 AM, Tom Herbert wrote: >>> UDP fragmentation would only with UDP, it doesn't help any other >>> transport protovcol. >> >> Stream transports already do this for the entire stream. >> >> The only other exception might be DCCP - I'd have to check that. >> > IPsec, GRE, MPLS, Ether/IP, IPIP, etc.
These are not transport protocols. My point is that your proposal doesn’t help transports. If a transport can avoid net-level frag, it’s always better to do so (see PLPMTUD). > The whole point of having > things like fragmentation into the network layer Yes - at the network layer for those. Which is what IPv4 and IPv6 already support. Your proposal buries a pseudo-net layer inside a transport - at which point we don’t need the pseudo-net layer, at least not for fragmentation. > is that it applies to > all protocols and we don't need to "reinvent the wheel" every time a > new protocol comes along. > >>> Also, I don't understand how the fragmentation >>> extension header, which has been defifor over twenty years and is >>> now part of an Internet standard, can be called "obscured layering". >> >> Not IPv4; the one where the network EHs would be buried after a GUE >> transport header. > > If by "network EHs" you mean Hop-by-Hop options, the draft specifies > how intermediate nodes can parse them in the GUE payload, and a magic > number is used to ensure with high probability that a middlebox is > indeed inspecting a GUE packet. Yes - boxes that don’t do IPv4 options for performance reasons will *magically* now support this extra work (thus the magic number?) You specify how that can be done by examining headers nobody currently supports. So when (or if) nodes upgrade, they’ll be able to do something they currently refuse to do (that is simpler). > Also, there is no requirement that any > intermediate nodes must process IPv4 Hop-by-Hop options. RFC1812: 4.2.2.1 <https://tools.ietf.org/html/rfc1812#section-4.2.2.1> Options: RFC 791 Section 3.2 <https://tools.ietf.org/html/rfc791#section-3.2> In datagrams received by the router itself, the IP layer MUST interpret IP options that it understands and preserve the rest unchanged for use by higher layer protocols. Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
