RE: New Approach For Discussing IPng

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 19 April 2021 08:33 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D96A3A2894 for <ietf@ietfa.amsl.com>; Mon, 19 Apr 2021 01:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 ckIUbez0L98Z for <ietf@ietfa.amsl.com>; Mon, 19 Apr 2021 01:33:49 -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 676013A2890 for <ietf@ietf.org>; Mon, 19 Apr 2021 01:33:49 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FP0Jl0wgQz68BHY; Mon, 19 Apr 2021 16:26:15 +0800 (CST)
Received: from msceml706-chm.china.huawei.com (10.219.141.145) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 19 Apr 2021 10:33:41 +0200
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.2176.2; Mon, 19 Apr 2021 11:33:40 +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.2176.012; Mon, 19 Apr 2021 11:33:40 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Phillip Hallam-Baker <phill@hallambaker.com>, Joe Touch <touch@strayalpha.com>
CC: Lloyd W <lloyd.wood@yahoo.co.uk>, IETF Discussion Mailing List <ietf@ietf.org>
Subject: RE: New Approach For Discussing IPng
Thread-Topic: New Approach For Discussing IPng
Thread-Index: AQHXNNgIJgIjqFwiD0eSEtq4kFgSsaq7bDQQ
Date: Mon, 19 Apr 2021 08:33:40 +0000
Message-ID: <70c33ddb14a44de79062ce75a1b3472e@huawei.com>
References: <CAMm+LwhV01N_uuFV8TfiyegpqDLmUYwxBcmkUAGG-HfJ7vSB+Q@mail.gmail.com> <989A5048-5EA8-479B-9231-D61B646E46F5@strayalpha.com> <CAMm+Lwhy0c6G7YLx8n7Ya7psG6VxcEckk-ncKg750rscuz-Yaw@mail.gmail.com> <89f2c243-433c-fa32-7dbf-c6392fde3da6@gmail.com>
In-Reply-To: <89f2c243-433c-fa32-7dbf-c6392fde3da6@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.200.69]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZSX7IC9GoJ7SXE_totWjcLr2xjU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 08:33:54 -0000

The Internet is the "dumb pipe" because only 5% of traffic has been paid for QoS (even inside one AS). The rest is BE.
Many Carriers are trying to improve this situation for many years but the reality is still close to 5%.
Hence, all these fancy QoS features are not needed on the Internet.
5% of traffic could be easily prioritized in the simplest "Strict Priority Queue" (for the smallest jitter) on the shortest path (for the lowest latency).
EH is just not needed for QoS. Almost nothing is needed for QoS.

Virtualization is needed on the Internet for traffic isolation.
MPLS did play this role for 23 years. EH was too complicated for hardware to replace it yet.
EH is the nested 2 layers model (options inside separate headers) with variable length size at both layers that pose the real challenge for processing.
MPLS is extremely simple to compare to EH hierarchical model.
Data Plane is becoming stronger and stronger - it is probably possible (or would be possible very soon) to squeeze EH hierarchy into PFE.
If MPLS would add a little more complexity to headers ("argument" for the particular application?) - it would be possible to implement it on the current level of PFE development.
It is still not known: will EH replace MPLS or not? Carriers still have to vote by money.

TE is needed. But not 10 versions of VTN that is promoted now in IETF - it is for QoS that is not needed.
TE should have the capability to leverage all investments into infrastructure. In simple explanation:
"all links from one node at the busy hour should have equal % of load independent of links sizes and directions".
It could save 2 digits (in %) for overall infrastructure cost. Primarily on fiber and DWDM layers because the cost structure for fiber:DWDM:IP is like 10:3:1.
We still have only 15y old CSPF with auto-bandwidth for Control Plane implementation of Traffic Engineering (to manage utilization).
Some vendors have an excellent implementation for Management Plane (SDN), but it would not fly because no horizon for it to become multi-vendor.
Nobody did try to use EH as the solution to this problem. This problem is just dropped from the agenda.

IMHO: it was a big mistake to group EH in a hierarchy of variable size objects. Hardware PFE did not exist at that time (it was invented 2-3 years later).
It did look acceptable for software processing at that time (single-thread) but it is not the best even for software now because the software has become multi-thread multi-core (it was the only possibility to improve computing power for the last 14 years). EH structure is not welcome for parallel processing or selective processing.
PFE has achieved the capability to support this complexity only now, but it is still questionable how comprehensive this support could be.
IMHO: it is not possible to fix EH - it would have a very limited permutation of supported features for a long time to come.

Conclusion: Additional complexity should not be the driver for next-next generation IP. We already have an EH example.
The primary design rule was already famous at the time of IPv6 development: KISS. The bare IPv6 header has an excellent fit for it.
Add a little more complex MPLS than we have now. That’s what we need for the Internet.

PS:
The situation could be very much different for Intranets (private networks). They may have enough important traffic to deal with a very complex QoS.
Ed/
-----Original Message-----
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Monday, April 19, 2021 7:53 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>; Joe Touch <touch@strayalpha.com>
Cc: Lloyd W <lloyd.wood@yahoo.co.uk>; IETF Discussion Mailing List <ietf@ietf.org>
Subject: New Approach For Discussing IPng

I've been keeping clear of this thread, but I think Phill does remind us of an important point (hence the small change of subject):
On 19-Apr-21 15:42, Phillip Hallam-Baker wrote:
...
> We keep having people coming along making these suggestions for IPv8, IPv10, etc. etc. and the inventors never once seem fit to ask what is so different about their proposal it can't be done in IPv6.

Back in 1994, it had become clear that deploying new header options in IPv4 across the Internet was in practice impossible, however well they worked in the lab. Extending IPv4 was therefore theoretically possible but impossible in reality. So we started IPv6.

27 years later, it has become clear that deploying new extension headers in IPv6 across the Internet is in practice impossible, however well they work in the lab.

There's little prospect that things would be different if we repeat the experiment.
 
> The whole point of the Internet is the narrow waist is really simple.

As it is written: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible."

(What about deterministic networking? Indeed, that requires support as a feature of the communication system. Therefore, it will never happen across the Internet as a whole.)

    Brian