Re: [v6ops] draft-vasilenko-v6ops-ipv6-oversized-analysis-00

Joseph Touch <touch@strayalpha.com> Sun, 21 March 2021 16:23 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143BC3A0FC2; Sun, 21 Mar 2021 09:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.972
X-Spam-Level: **
X-Spam-Status: No, score=2.972 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.517, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, 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 KZ4E4D0sHK63; Sun, 21 Mar 2021 09:23:20 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 35BA13A0FBF; Sun, 21 Mar 2021 09:23:20 -0700 (PDT)
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=JeZMh2/u1WjFlCeOAjHg8lCsvmdlCg+2KK7piIWfUD0=; b=Ivfx3ohWAyvKFBhF+yYC5Y2Ni uF23Y4FIyvonrFThu/Av+EtQpM8lopfgqHqVido4seY2wxROf6CU8tno+zRQscBbX+HmNUX2v/Ajm khNNYt+2qZBAdZikG3i1juICk1fL1XLM0RT+fwfjvKYoNslnSacoG0SAPsWHwmjDi8oVmfppFY7Js 1nwq+l9E9/XBcKECNNGuGw4X1cNbp/RYp+ssIr3dkFJbaK3xocj2kfOrxvC6cJwMPyas4S+VHJ8qi En1SZNkwM1chGtU23xZvy/awmGOKhqs+OBV7kBR0JaU3lkTcQIhrY/XghK1VqNLFN0qDSzSclI1Gx Ql9RypSzw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51435 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <touch@strayalpha.com>) id 1lO0rC-001ahT-BM; Sun, 21 Mar 2021 12:23:19 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F9E96B3-CF31-4874-9832-374F99818A50"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <1c9b61091e4748b68ea94b5eb9dfc6f5@huawei.com>
Date: Sun, 21 Mar 2021 09:23:12 -0700
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, int-area <int-area@ietf.org>
Message-Id: <B1BE7CC6-9966-4DB3-9C2C-F1A6C68EFB61@strayalpha.com>
References: <1c9b61091e4748b68ea94b5eb9dfc6f5@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-OutGoing-Spam-Status: No, score=-0.5
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/v6ops/ByxqLLmeiHo8q4JUepUMOFocTkM>
Subject: Re: [v6ops] draft-vasilenko-v6ops-ipv6-oversized-analysis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Mar 2021 16:23:25 -0000

Hi, all,

Spoiler alert if you don’t want to read the whole post:
	- draft-vasilenko makes erroneous claims as to the content in draft-tunnels
	- draft-tunnels and draft-vasilenko are consistent (once the latter is corrected) in their mutual conclusions
		- draft-tunnels on the need for fragmentation over finite MTU paths
		- draft-vasilenko in encouraging increases in those finite MTUs

Joe

---

First, draft-ietf-intarea-tunnels is discussed on the int-area list; after review of the information below, if you still believe there are issues to be addressed in that doc, you should post them there.

The technical errors in RFC2473 have been indicated in that document since draft-ietf-intarea-tunnels-01, posted in July 2015. They remain accurate, IMO. 

Note that I ceased performing in-place updates of that document because of *lack of active discussion* and because in-place updates are a waste of my time.

I am glad to see someone in IPv6 interested now, and would be glad to update my draft as needed.

FWIW, having read your doc, here are its errors in misstating the content of my draft:

- your doc mistakenly assumes that mine requires IPv6 hosts to send 1500B packets if they can, even if tunnels are on the path
	as with any IPv6 path, the source should send fragments no larger than the entire path can transit, whose reassembled size is no larger than the receiver can reassemble
	those original fragments are what enter the on-path tunnels, so they should be no larger than the tunnel egress can fragment
	and those original fragments would be encapsulated and then source fragmented by the tunnel according to the same (recursive) policy

- nothing in draft-tunnels assumes ICMP PTB cannot adjust these sizes or that the tunnel cannot use PLPMTUD
	see sec 4.3.1 of v10

- draft-tunnels does not “introduce” a new variable called tunnel MTU; I introduced the terminology, but the concept is as old as tunnels
	I coined that term to refer to the MTU across the tunnel with reassembly at egress (which already exists), as different from the MTU between ingress and egress (which I call tunnel MAP)
	sec 4.2.3 of v10 doesn’t claim this value cannot be set; in explains that PMTUD has no role in discovering its value:
	  Note, however, that PMTUD never discovers
 	  EMTU_R that is larger than the required minimum; that information is
  	  available to some upper layer protocols, such as TCP [RFC1122 <https://tools.ietf.org/html/rfc1122>], but
  	  cannot be determined at the IP layer.
	I never said it cannot be discovered
		it should be (e.g., by a tunnel configuration protocol)
		note that there are no current protocols that do this, even without tunnels (i.e., discover larger EMTU_R)
		I can add that point as clarification

- draft-tunnels does not increase IPv6 fragmentation
	please indicate why you believe it would (notably here "a considerable increase in fragmentation is proposed for the reasons of academic purity”)

- draft-tunnels does not claim fragmentation is the only solution to oversize packets
	it addresses how and where to handle tunnels in the presence of packet limits, of which path MTU is only one

- ICMP PTB is not a solution out to the origin source
	that would potentially drop the IPv6 path MTU below 1280, given enough tunnel overhead (or layers thereof), a violation of IPv6
	so yes, in that case, the ONLY solution that preserves IPv6 in the presence of tunnels with that much overhead would be ingress source fragmentation

- sec 3.3 of my doc DOES allow ICMPs to be relayed back to the source
	it merely states that they should be generated when a packet too large to ingress arrives, 
	NOT when an internal tunnel ICMP is received by the ingress

	the point is that the origin source sees the ingress as a router on the path,
	so it should get ICMPs from that router only when packets arrive at that router, not when its tunnel fails downstream

	this makes ICMP relay *easier* and more reliable to implement; the ingress gets tunnel ICMPs to learn the tunnel’s effective link MTU,
	then uses that link MTU to send ICMPs back

	yes, this is to allow the tunnel to act as the link *that it is*, but it does not prohibit ICMP info from flowing back to the source

And finally:

- nobody is claiming we shouldn’t increase link MTU
	draft-tunnels would still be relevant, no matter how large the MTU is, for the reasons I state in that doc

One other observation:

- your statistics for fragment drops apply only when the fragment is visible to the IP layer
	there are intermediate layers that hide fragmentation for exactly this reason, e.g., UDP tunnels, GRE, etc.

---

> On Mar 21, 2021, at 1:59 AM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
> 
> Dear Experts,
> I have seen many recent activities in IETF related to MTU problems. Well, maybe not so active as some others, but active anyway. Many other active drafts are evaluated in this draft.
> I had an idea what is the right way to solve problems in this area, but after the research, it has been found that foundations were discussed in RFC 2473 (Dec 1998). Just people have forgotten about it.
> We have discussed it with co-authors and we have decided that it make sense to publish the research because it looks at the problem in a systematic approach.
> 
> The one thing that is alarming in this research: draft-ietf-intarea-tunnels is pushing for much more fragmentation for pure Academic reasons. This draft is already referenced by many other documents.
> I believe that not many people have spent enough time to understand it's complexity to reveal the truth: the majority of the IPv6 traffic would be fragmented if it would follow draft-ietf-intarea-tunnels.
> 
> Thanks to everybody who would spend enough time to produce comments.
> Eduard
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Friday, March 19, 2021 11:07 PM
> To: Dmitriy Khaustov <dmitriy.khaustov@rt.ru>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Vasilenko Eduard <vasilenko.eduard@huawei.com>; Xipengxiao <xipengxiao@huawei.com>; Xipengxiao <xipengxiao@huawei.com>
> Subject: New Version Notification for draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> 
> 
> A new version of I-D, draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> has been successfully submitted by Eduard Vasilenko and posted to the IETF repository.
> 
> Name:		draft-vasilenko-v6ops-ipv6-oversized-analysis
> Revision:	00
> Title:		IPv6 Oversized Packets Analysis
> Document date:	2021-03-19
> Group:		Individual Submission
> Pages:		19
> URL:            https://www.ietf.org/archive/id/draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-vasilenko-v6ops-ipv6-oversized-analysis/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-vasilenko-v6ops-ipv6-oversized-analysis
> Htmlized:       https://tools.ietf.org/html/draft-vasilenko-v6ops-ipv6-oversized-analysis-00
> 
> 
> Abstract:
>   The IETF has many new initiatives relying on IPv6 Enhanced Headers
>   added in transit: SRv6, SFC, BIERv6, iOAM. Additionally, some recent
>   developments are overlays (SRv6, VxLAN) over IPv6. It could create
>   oversized packets that need to be dealt with. This document analyzes
>   available standards for the resolution of oversized packet drops.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops