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

Joe Touch <touch@strayalpha.com> Fri, 08 March 2019 23:57 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD7F1277E7 for <int-area@ietfa.amsl.com>; Fri, 8 Mar 2019 15:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf6YPAdwuT4O for <int-area@ietfa.amsl.com>; Fri, 8 Mar 2019 15:57:43 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBF2126DFA for <int-area@ietf.org>; Fri, 8 Mar 2019 15:57:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jY3XAOzVttHXQa9t6XuimMa7cfuw9JhJAkz2v7RS2U4=; b=m5NaR0Hmm10Kpk1iAzGdz5CA0 xzgBBXR8TdQZEcf00NSryEZgEjQBXwPRJgLyqcPCfh70dq6EaQ7Bq5aZDSAceZAniFiW2wpC0RRGV 1Qf2gSKCE7ANsW0D8on6wn4J6XeoC1scUU++Fo4+2+7c0lZYX962gDsLkDh4TDdFRepOWncybChiR U0rsgthYo165olslHAZ4tKWH4mIeTEeGOrBeeWNVuelPym914JEMsxe8kOb5WHjSXsfCdMUq3GDaK 1Qds6lwJiaaNPhvNHBPPjxYUAdh3XmUAg2iyyGNx9Jg2gs7hNsPN47wAuKAXwy+M2JtYQLRACd7Nr T5ReeE9pQ==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:63100 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1h2PMy-003Sp3-Jq; Fri, 08 Mar 2019 18:57:42 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_B50659CD-4F4F-4D48-AC95-848957244DB6"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CALx6S34WMNVBqy8vWZ+rmjDaZNS4U8r8Euqxqy_aFo=xq7uH4A@mail.gmail.com>
Date: Fri, 08 Mar 2019 15:57:39 -0800
Cc: Tom Herbert <tom@quantonium.net>, "int-area@ietf.org" <int-area@ietf.org>
Message-Id: <58598B13-7EAC-4C6B-92A3-961136200701@strayalpha.com>
References: <155129875579.13940.18077034152695268824.idtracker@ietfa.amsl.com> <CAPDqMeofwtqye_+55Yc_3rAkQqNLQ9Dw9TohJ7gcYCgUJrs-Jg@mail.gmail.com> <dbcef0c979f24aecb638babded309117@boeing.com> <CAPDqMeryKrE2t47kY1YXcpf80bJ8W3cx9m3UX+vfiYTy_kE6yA@mail.gmail.com> <f292b3ef-eca5-77b8-d542-59af19c6c984@si6networks.com> <CAPDqMeoPV8piL1YM-5Uk3coe3Vf-Aaed79yCZMQdzt=VdfMamw@mail.gmail.com> <e77bacb2-b71d-cff1-4c94-e2243d4437bb@strayalpha.com> <CAPDqMeqVoZP72Vzn09qXDV-Eqo+jtB9=bHs9y-io2wRopB5sLQ@mail.gmail.com> <299787b9-a0c9-0c5d-ea58-ef990db2bf14@strayalpha.com> <CALx6S34WMNVBqy8vWZ+rmjDaZNS4U8r8Euqxqy_aFo=xq7uH4A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/oM-4xwe1o2pSJCyrP6qqHucz9tw>
Subject: Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 23:57:46 -0000


> On Mar 8, 2019, at 10:01 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Fri, Mar 8, 2019 at 9:42 AM Joe Touch <touch@strayalpha.com> 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