Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

[Tom Herbert <[e-mail]>]

On Fri, Mar 8, 2019 at 3:57 PM Joe Touch <[e-mail]> wrote:
>
>
>
> On Mar 8, 2019, at 10:01 AM, Tom Herbert <[e-mail]> wrote:
>
> On Fri, Mar 8, 2019 at 9:42 AM Joe Touch <[e-mail]> 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.

The draft is clear on how intermediate devices can parse that.

>
>
> 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).

That's not true. GUE has been in deployment for quite a while and the
extension header encapsulation is already supported by virtue of the
design. IPv4 extension headers have not be developed as of of yet,
however adding host support is easy. Intermediate nodes parsing of GUE
(which again is optional) is not particular difficult either given the
emergence of programmable network devices.


>
> Also, there is no requirement that any
> intermediate nodes must process IPv4 Hop-by-Hop options.
>
>
> RFC1812:
>
> 4.2.2.1 Options: RFC 791 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.
>
>
Not an applicable requirement. Hop-by-Hop Options are not Ipv4 options.

> Joe
>