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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 23 March 2021 19:10 UTC

Return-Path: <vasilenko.eduard@huawei.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 28FF13A11DC; Tue, 23 Mar 2021 12:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 fFda5iDaeA4Q; Tue, 23 Mar 2021 12:10:31 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986113A11E7; Tue, 23 Mar 2021 12:10:15 -0700 (PDT)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F4gmn3pvRz680QT; Wed, 24 Mar 2021 03:05:29 +0800 (CST)
Received: from msceml704-chm.china.huawei.com (10.219.141.143) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 23 Mar 2021 20:10:13 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 23 Mar 2021 22:10:12 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2106.013; Tue, 23 Mar 2021 22:10:12 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Joseph Touch <touch@strayalpha.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, int-area <int-area@ietf.org>
Thread-Topic: Proxy function for PTB messages on the tunnel end
Thread-Index: AdcfDpZejD7P5RAGQ06oVS2C5lk8jAACE+sAAAi5WeD//90TAP//s51QgAByGQD//8LNQIAAUjUA//8J3tAARFNWgP//xB4Q//+RtwD//uUYkA==
Date: Tue, 23 Mar 2021 19:10:12 +0000
Message-ID: <46be60a38c0f4bc08f352dc8ed353c6a@huawei.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>
In-Reply-To: <D87C00F7-2902-48C4-9DCA-E1019EF32CAA@strayalpha.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.202.107]
Content-Type: multipart/alternative; boundary="_000_46be60a38c0f4bc08f352dc8ed353c6ahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uO3s_H_LK3LNGk4qpm_Q6GIJCRk>
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: Tue, 23 Mar 2021 19:10:36 -0000

Hi Joseph,
I am not much interested to discuss IPv4 now. (despite that 2 MTUs for one interface is absent there too)
Let’s look at your reference to RFC 8200.

Section 4.5: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path
It means that all these discussions about fragmentation and reassembly are not related to transit nodes. It is for the “source and destination nodes”.
The better terminology is “transit node”, “destination node” – like it is in RFC 8200, not “host” or “router”.

You see – nobody is asking vendors to be compliant with any reassembly buffers in transit. Because it was assumed that would be not reassembly at transit.
Hence, vendors had the freedom to choose a much bigger number than 1500 when reassembly did happen in reality (despite IPv6 architecture decisions).

Please, show any evidence (or just claim if you could not disclose) that any vendor has 1500B (or less) for reassembly in the data plane (on transit node).
I neither know nor care. That’s a compliance issue, not a standards issue.
It is not a compliance issue, because there is no regulation/standard to comply with. Vendors had the freedom and solved the problem easily.

This is described in detail in:
            RFC1858
            RFC4459
            RFC4944
            RFC6946
            RFC6980
            RFC7588
            RFC8021
            RFC8900
I did not ask for a general discussion. Of course, fragmentation is a big topic with many publications.
I did ask for any evidence that there is 2 MTU per 1 virtual interface and fragmentation problem as the result of this (when packet would come in between of these MTUs).

I don’t see why you’re stuck on this issue.
Because you are trying to introduce additional fragmentation to the area where it was absent before. The root cause is the introduction of the second MTU per interface (that is in the reality the buffer size).
2 MTUs for one interface is the innovation. It does not exist in any standard or any real implementation. It is invented only in draft-ietf-intarea-tunnels.
It is not just new names and new classification. It new things that does not exist in the real world. Harmful, because of additional fragmentation introduced..

Eduard
From: Joseph Touch [mailto:touch@strayalpha.com]
Sent: Tuesday, March 23, 2021 9:00 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: v6ops@ietf.org; int-area <int-area@ietf.org>
Subject: Re: Proxy function for PTB messages on the tunnel end

Hi, Eduard,


On Mar 23, 2021, at 8:47 AM, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:

Hi Joseph,
Please, show any except (or section number) from any RFC that push vendor to use 1500B buffer for reassembly in the data plane on the transit node? (or any other number on the transit node)

The Internet defines:
            - nodes that create or consume IP packets are hosts
            - nodes that relay IP packets are routers

RFC1122/1123 summarizes host requirements. RFC1812 summarizes router requirements. - both for IPv4. For IPv6, the former is largely in the IPv6 spec RFC8200 and RFC8504 and the latter in RFC8200, though there are some useful observations in RFC7084.

To your question, assuming you’re speaking of IPv6, RFC8200 requires nodes that consume IPv6 packets to support 1500B reassembly.
RFC791 requires that nodes that consume IPv4 packets support 576B reassembly.


Please, show any evidence (or just claim if you could not disclose) that any vendor has 1500B (or less) for reassembly in the data plane (on transit node).

I neither know nor care. That’s a compliance issue, not a standards issue.

Please, show the evidence that the fragmentation problem exists.

This is described in detail in:
            RFC1858
            RFC4459
            RFC4944
            RFC6946
            RFC6980
            RFC7588
            RFC8021
            RFC8900

As well as nearly any tunnel protocol description.

All your discussions for EMTU_R are not relevant – it is for *host* reassembly buffer.

See above; you need to understand that the Internet defines HOST as any device that creates or consumes IP packets.


Data Plane on the transit node has not been regulated before – It was not needed. Vendors have chosen big enough numbers that did not affect anybody so far.

See above; that’s not correct.


It was effectively 1 MTU restriction per 1 virtual interface, not 2.

I do not accept this:
That’s just the case where pathMTU == EMTU_R.
That means the EMTU_R is not needed *in practice*, but in principle it still exists.
If particular tunneling technology does not have a reassembly buffer (reject fragmentation in principle) – we could not talk about it like it exists.

I don’t see why you’re stuck on this issue. You don’t have to implement a separate reassembly buffer to have an implementation behave exactly as if there was one with the same size as the pathMTU. The effect is the same - no reassembly.


If you would look to microcode – you would not find it. We could go very far with such logic.

I don’t take my cues from others’ implementations.

Joe