[v6ops] draft-ietf-intarea-tunnels concerns

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 25 March 2021 10:52 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 1830D3A1D73; Thu, 25 Mar 2021 03:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 EA6YbYZgGZbW; Thu, 25 Mar 2021 03:52:39 -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 17EB93A1D70; Thu, 25 Mar 2021 03:52:39 -0700 (PDT)
Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F5hXx1bGBz683s2; Thu, 25 Mar 2021 18:43:45 +0800 (CST)
Received: from msceml706-chm.china.huawei.com (10.219.141.145) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 25 Mar 2021 11:52:34 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 25 Mar 2021 13:52:33 +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; Thu, 25 Mar 2021 13:52:33 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: int-area <int-area@ietf.org>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Thread-Topic: draft-ietf-intarea-tunnels concerns
Thread-Index: AdchXcgc+BNv8UaCSiCbTZn958h4xA==
Date: Thu, 25 Mar 2021 10:52:33 +0000
Message-ID: <67a4aeb99dc6464c913516d744aa27bd@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.145]
Content-Type: multipart/alternative; boundary="_000_67a4aeb99dc6464c913516d744aa27bdhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/GUuy_4WUVCWAMv4tDT26jAf1_HM>
Subject: [v6ops] draft-ietf-intarea-tunnels concerns
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 10:52:42 -0000

Hi Experts,
I have not received answers (after a long message thread) for me to understand:


1.       It is assumed by the draft that Data Plane in the transit router operates right now exactly like a host. Then Generalization is attempted for IP stack operation like on a host.

It is not the case. Moreover, it is not possible in principle because the hardware is ASIC managing traffic flow, but the host is CPU “running to completion” for control flow. The architecture of hardware is completely different.

2.       It is additional complexity: 2 MTUs for one virtual interface instead of the current 1 in all real data planes. 1st MTU is the buffer size - called “Tunnel MTU”. 2nd MTU is the old tunnel MTU- called “MAP”.
It looks extremely bad after the decision that 1st MTU (buffer size) is static till some miracle would explain to us how it would become dynamic in the future.

3.       The draft has deprecated PMTUD and introduced fragmentation instead of it. To be precise: for all bulk traffic that would happen between MTUs.
Moreover, It is not explained what to do for tunneling that does not want fragmentation now (currently prefer PMTUD). Should all tunnels support fragmentation from now on? (L2TPv3, VxLAN, MPLS, RFC 2473)

4.       If PMTUD is deprecated, then why it is still used for the 2nd interface MTU? If it is dead, then it is dead, right? Anyone could have the conclusion that the 2nd MTU is static too.

5.       The draft does break all tunneling specifications. Is everything should be changed in production? It is the cost. For what reason?

It does affect IPv6 too – I had stumbled upon this problem from that direction. RFC 2473 is the best tunneling spec that would be damaged severely.
Hence, 6man and v6ops on the copy.

I decided to leave it here for the people that may search for it in the future.
Eduard