Re: [v6ops] Proxy function for PTB messages on the tunnel end

"Black, David" <David.Black@dell.com> Thu, 25 March 2021 16:46 UTC

Return-Path: <David.Black@dell.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 B11993A2744; Thu, 25 Mar 2021 09:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Level:
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.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 HY1Y2wgxF92m; Thu, 25 Mar 2021 09:46:37 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 993553A2748; Thu, 25 Mar 2021 09:46:37 -0700 (PDT)
Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12PGfn5P024560; Thu, 25 Mar 2021 12:46:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=PlTRPTsP4yUzHWd6ug2G3GI53nOy/+XH1PTFIgnrwDQ=; b=ZN6BzMzmGkOSoRbh+aenlIPFWAK+U7zFgV/k/9gxIKp2waZMA7PXWIhzomd7Qnrhz3mR RiR/xXBD2bB24IXlaothHqlHC/rEhgI0Bgs3BjhG9wlldM+ajistgrH2+Zwi3/gIuqyt MFsQCVTZykuQ1lQRIh4CBhPcfZKfossLvjfz/FlkD4I2Wt528hSaApxvQ9g9Ijk25VJP x7sQZYqGKHtMXLoDvEYxnUeYYWRP3jSQwhhXIZDgNRcPE9mqg5/9jPofu2JALCNd4N2K GfeR7IMUKcKz8VoAIblZE57xofYZxeFOEu+xjwUJIbPmw30UF+WfjJZ2WlefaEKl5OGW TQ==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 37dc43k4m2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Mar 2021 12:46:36 -0400
Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12PFiu3T058295; Thu, 25 Mar 2021 12:46:36 -0400
Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-00154901.pphosted.com with ESMTP id 37dxq4d5ua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Mar 2021 12:46:34 -0400
Received: from m0142699.ppops.net (m0142699.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 12PGYlHQ186259; Thu, 25 Mar 2021 12:46:31 -0400
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by mx0a-00154901.pphosted.com with ESMTP id 37dxq4d5t1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Mar 2021 12:46:29 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UWz+0mTpxYla3ECIpebEdgz1qZiuT6tYx9OePLgp4TEo9NfILQVLlwurYidst/c0712R9KbrPR+dAscY5QWwvTMZLFEiwBvItjPF14F667NMkuiduUMJtoqa0DrDbGh/La/mkexP/UTj8RErbW0mib0zItpQPFY10O0Ywac6MN5HIwKjAWhZ91Uo1Cdypb0VZtblbh55W1jAkjUWbSqvyDMRrD0ej8A4DD5YQ8Vo461eti5OHO0gnTVBLTdpILnuarVEB9VyxRV0/zYay4xHgD2NQafHBW1jC+vhwdjGE2xRsaj3Nn19B+DtYYYuLaRz+91X5WPPisN4cVsffh0GoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PlTRPTsP4yUzHWd6ug2G3GI53nOy/+XH1PTFIgnrwDQ=; b=kOmRZ4qfF/At/YbnC1TFkWRB+SrE8S+MYk971USu+4AYLhxZ9l9jO+fJcx+jTBcSRgzfA/YpoFdLyxlWNUVkkfsYQle/cZJb0HPgHrFGohlbvs2t+GEVB0ycAN2t/2mXZk7GO4szC8cIX8OSkcugpFj5ozhtZgv2Ue4DevVsv4ng4hOMdbTrgsDGa7zeLq2sIBWEgpY/HZsE5aFWa4UAPvyM1652QmqyAjGrrcuNO3HnIi46I6/EiUQm7aujP/BKBUpmgDnNw4JwTpbUbZ4OIh9giezjNQBDsZ+h2WIJgXM0Ubi8mrLk2o3/DJ7Fz4qTs8j30Y7mBXQr/Tkdw5Pm7A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by BLAPR19MB4243.namprd19.prod.outlook.com (2603:10b6:208:27a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.25; Thu, 25 Mar 2021 16:46:26 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b1f3:f51d:c01c:2feb]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b1f3:f51d:c01c:2feb%6]) with mapi id 15.20.3977.024; Thu, 25 Mar 2021 16:46:26 +0000
From: "Black, David" <David.Black@dell.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, Joseph Touch <touch@strayalpha.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, int-area <int-area@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: Proxy function for PTB messages on the tunnel end
Thread-Index: AQHXIOkkohrZRJlWs0mtJYPIrjdk6qqTkqIAgADkg4CAAHFAIA==
Date: Thu, 25 Mar 2021 16:46:25 +0000
Message-ID: <MN2PR19MB404524DF4CB3749D38A2094B83629@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <0b61deabe8f3420eba1b5794b024e914@huawei.com> <A063E98C-0D6C-49B2-B871-E2B39A097FD5@strayalpha.com> <37059faadd6e441cb98f6ec7e01ecef9@huawei.com> <9D23C833-46C5-4B93-A204-D2D4F54689DF@strayalpha.com> <1e6ecd3b468d4255bda65d519190135d@huawei.com> <3B48413C-A47D-4F3F-B9E4-7ED4D33AA66B@strayalpha.com> <22bb7bf129694ccfbbad441d8d22e05c@huawei.com> <A5F62B47-DBA3-457D-89CD-D570EA2EA886@strayalpha.com> <eb63d427f4d34e44908ccee2c2d14073@huawei.com> <F158C443-6E73-4FC6-ADCA-6D28EE8F0A30@strayalpha.com> <d1c8a80b387847a3b00566e3dc0768ab@huawei.com> <D87C00F7-2902-48C4-9DCA-E1019EF32CAA@strayalpha.com> <46be60a38c0f4bc08f352dc8ed353c6a@huawei.com> <4E4C25CB-561C-4BF1-B99B-14E26D00009B@strayalpha.com> <4415086a1b734313b383307a27eb3fb2@huawei.com> <1A41F380-5176-4856-B0FE-BCA065FEAB15@strayalpha.com> <d2dffa85fdbc476f95c008a41e65e696@huawei.com> <8CB230FB-D5D9-4EE2-BA61-7FBC786D09CA@strayalpha.com> <c3ac993dc35340648988c688f1b86bbc@huawei.com> <61E1D204-B806-4D11-86D1-F175ED38A96C@strayalpha.com> <348c2c09d1ad4a7dbac4add24bbb5ab8@huawei.com> <MN2PR19MB40450A07EAF2FC2BD5439F2983639@MN2PR19MB4045.namprd19.prod.outlook.com> <6a9c2f22ed0b4ffab4fedb12bb39a7d0@huawei.com>
In-Reply-To: <6a9c2f22ed0b4ffab4fedb12bb39a7d0@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2021-03-25T16:45:14.9232332Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=f40a8741-24d0-4465-bb74-8e01b1ccbb03; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=dell.com;
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0179c951-1fbb-4a36-7ab1-08d8efad87e7
x-ms-traffictypediagnostic: BLAPR19MB4243:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BLAPR19MB4243A2465799AC161695503983629@BLAPR19MB4243.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: id09I1Ob9uPxZhBrNEjYvIvEmZ5STxxfuM7AZmhfwwGghbQ8VKX3A/50tYoqwLKOIYl6jimZryphdJLe4hL6SXanLnWMqw9QXVmbmIJR3ctPrnMhwDipmyFQXARWWrY2WbeNxo6+Vg/vSdoUx6e4f0k9JHKxtSN191jSc2PkbE2+1nl15Eg5KnGEDZicLzkH3KXcTmvTJvTOEExo3C4fCr4GTPWxiMaz5T2zgl1hpeuhlvjqr3OYncHj0PBKoH+037Ln7ldG5EQ80nxi9MSX3d4Vu61jxCAcKzfSbUESZOYZ7sm3kBC9bZzK3SkdXxjNYoMA2jM5rNNcZ8+Unm/ory0kgXZytbxW+E3CXv386tchq7kbh8TLssjP2RPuaqejQCAu7smeKF5H81y342ZTe2I5qcOy2xShGbSC1AB+5I0LQG1Pmj4kMWD5U3nc0rBancdecdHPo+NR2ofUsOewyqX+8IHZgUfyqEcmx/rtjfUvR+F5igL9yxp0zhI013/b26S4jtL7rEQwUarGw16LrpH5aUt5nH39MQaKxMh/M71kaLSzt9K1jyURP5wEH8cT+KTBbpuQxGa9YzlckBrHuu0TbUyK5OEukXSWb1w4XkX7KiOeGovSNyHWP/fDFtfve06f2+JxWIXuLFu8QBzA/huUh3dQG0enr7NjQGJamiA=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(366004)(136003)(376002)(39860400002)(107886003)(66446008)(66946007)(64756008)(66556008)(110136005)(66574015)(52536014)(76116006)(6506007)(2906002)(66476007)(53546011)(83380400001)(8676002)(478600001)(71200400001)(8936002)(86362001)(33656002)(9686003)(15650500001)(5660300002)(55016002)(38100700001)(786003)(4326008)(54906003)(26005)(7696005)(316002)(186003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 1suvqJVyKllnYthKDDNukEz2dxVU0oBmAOPMysKGCE4q0uS4BnlhpB0ILTrokcSW7fU6JfT60lNjILV+C6jmmUD0lkl53yKcSP20oSsB5Yjg3LpuJZVLi8mneG1ul4x3GOdHXRsr+iGYw1ezqdt4LuWCeux5smfffS37sgI2pDzGhaJyYgKLTokRsgXMJ0pM0MTQatzGR98gicIPg/zxpgs47ZUG8lObRnns1eQ4ovLH5sAGm/mWiDsBK5uB5No7SB0Owdo/NRxWSNr9KDRjm3Ga3muBz2389RtdcjzwaA3TwLPDlygtX6tdZ60quNa+/AkWd3s7pzgYXFMIqC9rHsiPYlXzUDS1ipOLr7rH0dmqZRQoKnIyA4I+0dn5c7wu77sDV3zxIoPb8wwOzmOM6tq0rvrNsOINImpN3UkGRg+4n8/dF57QYE5pVzKcaidYMXcJ4vG1RTZwApg4TlyG2Mt3sN7LxGngJ6S4LQjKH3YXWhatCtdh9P+q+f+GjmdlWy8arnacqbBwAGj6p/X9PpDuBzoCczDroVKO+cO5HcjwAZrjDLVMONFQ/5qC06lWEhGgUmaxiUxghgVSvPono8d99EvOOsQER9sfr7qoWTbdg8p5B74+F4hwLqPP+RsC/kyGamQVL/UuC2nHplVk0sC4chWnI/6zrxh5NGGbQlL0/m+qOKEfgRes532zpAq8frhGZd3PEiuA42LCemUGNBZY+4Q+8iQKvzdGgNamlsrSFY3bo/03YeLQBladBsFboF3yJhC3fIRqeybtuP16ltxROzbuP3YhihBVa6BY/L0YLNBNBLODayctcK2Hxjq6whsTDgj9C/yIXSiolyVNYLZ/tC88bhX6WU6kvw5AasodZQKXwItzADCZpymqDSIqAsMjeeCVX1ikq3Wr3tjKxSZE53mMWo+6HwqP55uLhr8S2oVHIwjiLJ2qNVJUj7CVvxmmAk0PdlW/tBJGppz61dNW/zh7Ebj6okqkcx0CRaJJJQ3LmK6scK20YkezXdTTKosx0EUhKcHml2OGTFz3IUexnv1ecuF4x/KYvwwn2zW0SJfhgpgVlrYt5kT+6JH1s+W6QwxkuIlyAW9rvY8mE1iUQY2Nyp1SsRjSMyJZQk1tQhJJR2M0UJZpYfV81JllK3XOhjn88Bw0Cd9gKToHW6GUfTz1jEYveE/z69RN9SDnRRRb8GswMOpEhjcuXYR8w/EQLeOSNPCCh1j/5Qs2gvAzA6XFcq4lnx3Dg/xqpIdKqfPkoK/hxDNs5/5ITNU0BPUE//Sib2+8zRFugnHFJSxloe0WeCx3A3L1WQC7K4HyaLeQvt5P8heEJUx7yRXB
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB404524DF4CB3749D38A2094B83629MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0179c951-1fbb-4a36-7ab1-08d8efad87e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2021 16:46:25.9976 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: n7UrAbcZohcnwwmAr0Zv34PbWgF9ALaAoq9uRyu8C+jtmfd14KJKobdY1+1lvdZxc+wfaEBnAZyiqotedFhgvA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR19MB4243
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-25_03:2021-03-24, 2021-03-25 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 impostorscore=0 spamscore=0 priorityscore=1501 suspectscore=0 adultscore=0 mlxlogscore=941 mlxscore=0 clxscore=1015 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103250100
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 mlxlogscore=950 bulkscore=0 suspectscore=0 mlxscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103250120
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/yzpfoC2l44EYFkGiezMaVlCWd1s>
Subject: Re: [v6ops] Proxy function for PTB messages on the tunnel end
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: Thu, 25 Mar 2021 16:46:43 -0000

Inline …

Thanks, --David

From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Sent: Thursday, March 25, 2021 5:52 AM
To: Black, David; Joseph Touch
Cc: v6ops@ietf.org; int-area
Subject: RE: Proxy function for PTB messages on the tunnel end


[EXTERNAL EMAIL]
Hi David,


  1.  Any real tunneling implementation does check the incoming packet against virtual link MTU, not against any buffer. Because buffers are “big enough” for tunneling that does support fragmentation/reassembly or buffer does not exist at all for tunneling that does not support fragmentation.
[David>] We agree on this.  The check against the virtual link MTU (which is EMTU_R in the draft) is what causes generation of the ICMP PTB.


  1.  Why you are talking about “NIC”, “driver”, “EMTU_R”? All these abstractions do not exist in hardware that is doing tunneling for us.
[David>] That is entirely about "the link-attached-to-host case, where an ICMP PTB may be counterproductive" which also needs to be covered, in addition to the router case that you're focused on.

It is the Data Plane ASIC, right? It deals with traffic flow (Verilog), not with control flow (RTC == Run to Completion, “C”).
[David>] That would be in a router, actual hosts that don't have data plane ASICs also have to be covered.

It does not have LINUX on board. No one would be capable to emulate “host” on this ASIC, at least not to degree that this draft demands.
[David>] The draft specifies abstractions – implementations optimize across them.

It was originally a very bad idea to unify tunnel end point with host – they are running on principally different hardware. The difference is much bigger than between RISC and CISC.
[David>] I disagree - tunnel encap/decap software absolutely also runs on actual hosts.  Remote access VPN clients are an obvious example.

Eduard
From: Black, David [mailto:David.Black@dell.com]
Sent: Thursday, March 25, 2021 12:10 AM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>; Joseph Touch <touch@strayalpha.com<mailto:touch@strayalpha.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; int-area <int-area@ietf.org<mailto:int-area@ietf.org>>; Black, David <David.Black@dell.com<mailto:David.Black@dell.com>>
Subject: RE: Proxy function for PTB messages on the tunnel end

Hi Eduard,

>>            - links NEVER *generate* ICMPs
>>            - routers and hosts *generate* ICMPs
> Why virtual link could not send ICMP PTB (like on a physical link)?

The short answer (IMHO) is "yes, but the host or router generates the ICMP PTB."  There's a subtle distinction here that better supports the link-attached-to-host case, where an ICMP PTB may be counterproductive.

Starting with a router case, suppose that a large packet arrives at a router whose forwarding table determines that the next hop is a virtual link that encapsulates the packet to send in a tunnel.  The router checks the MTU for that virtual link (tunnel EMTU_R), determines that the packet is too large to send, and the router generates an ICMP PTB to report that.  This works the same way for a physical link that just sends the packet (MTU that is checked is that of the physical link) – in both cases the router generates an ICMP PTB based on link (interface) information before attempting to send the packet on that link.

The host case enables a host device driver or network stack to deal with this situation without forcing an ICMP PTB to be generated and parsed.  Starting with the physical link case – attempting to send a packet that's too large for the NIC to send generates an error that propagates back up the host network stack – forcing generation of an ICMP PTB in this case may be counterproductive.  Exactly where that error is generated may depend on how  the network stack and NIC are implemented – the error could originate from the NIC itself, the NIC device driver, or a higher layer of the network stack that checks the link MTU before the packet is handed off to the NIC device driver.  For a software encapsulation implementation of a virtual link, the MTU (tunnel EMTU_R) gets checked at or above the network stack layer that does the encapsulation.  If there's a software router embedded in the host (e.g., virtual switch with IP forwarding functionality), that router could generate an ICMP PTB based on the error or on directly checking the link MTU.

Thanks, --David

From: Int-area <int-area-bounces@ietf.org<mailto:int-area-bounces@ietf.org>> On Behalf Of Vasilenko Eduard
Sent: Wednesday, March 24, 2021 4:05 PM
To: Joseph Touch
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; int-area
Subject: Re: [Int-area] Proxy function for PTB messages on the tunnel end


[EXTERNAL EMAIL]
Hi Joseph,
You have presented below (and in many other messages) a long list of policies (extensive usage of “SHOULD”, “NEVER”, “MUST”)
That are new – would change how current tunnels operate
And are not justified by any reasoning.
It is religion, not technology.

Why virtual link could not send ICMP PTB (like on a physical link)? Just because… it is “unsolicited”. But one moment – any other PTB is unsolicited too - It is an event.

You have not answered any of my questions – you continue to promote the solution from the draft-ietf-intarea-tunnels putting some excerpts in a different order.

PS: I am especially sorry that draft-ietf-intarea-tunnels would scrape the best tunneling RFC that we have for IPv6. RFC 2473 was really good.
Eduard
From: Joseph Touch [mailto:touch@strayalpha.com]
Sent: Wednesday, March 24, 2021 10:01 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; int-area <int-area@ietf.org<mailto:int-area@ietf.org>>
Subject: Re: Proxy function for PTB messages on the tunnel end

Two points:

On Mar 24, 2021, at 7:59 AM, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:

It would invalidate all tunneling implementations. It is not compatible with any one of them. PMTUD is killed. Revolution.

PMTUD is effectively dead, so if you’re worried about it, you’re 20+ years too late - as per the RFCs I’ve already cited.

All complaints against RFC 2473 are minor (if right),
Except this one that is definitely wrong:

       o Tunnel ingress issues ICMPs

This is a violation of RFC792 and 8200; the ICMPs issued are that of routers, not links. If the ingress is at the source host, these ICMPs would come from a device that is not a router.
ICMP PTB is very important to deliver to the traffic source.

I’m saying something very specific:
            - tunnels are links
            - links NEVER *genenerate* ICMPs
            - routers and hosts *generate* ICMPs
                        based on what happens inside them, e.g,, to their processes and links

So the question is “under what conditions does a link cause a router/host to generate an ICMP?”

There should be no unsolicited ICMPs, i.e., routers/hosts NEVER generate ICMPs unless in reaction to a packet being sent or received.

PTB means “I cannot send the packet over this link”. Not path - link. There is no PTB for a path; the assumption is that one link of a path that fails will send the ICMPs back to the source.

For a tunnel, when can it NOT send a packet?
            - only when that packet is larger than the tunnel EMTU_R (i.e., egress received max, reassembled if reassembly is supported)

A packet that can be fragmented and traverse a tunnel is not too big. It’s “bigger than you might like” or “bigger than desired”, but there is no ICMP to indicate that sort of ‘soft’ (non failure) error.

So what should happen:
            - tunnels ingress should know and update (if changing) the tunnel EMTU_R value
            - routers/hosts should use EMTU_R as the tunnel MTU
                        again, because the tunnel path MTU is a preference; the tunnel EMTU_R is the actual strict limit
            - routers/hosts sending packets over a tunnel generate ICMP PTBs as needed
                        again, the router/host generates the message, not the tunnel ingress
                        this happens when the router/host tries to send a packet over out that tunnel interface that is larger than the tunnel MTU

So this all works, as long as ICMPs are relayed.

Draft-tunnels does not deprecate this behavior. It describes it and explains why this is the correct behavior.

Tunnel ingresses that relay PTBs inside are broken; they fail in ways they do not need to. That is the true error.

Joe