Re: [v6ops] Are we competitive?

Xipengxiao <xipengxiao@huawei.com> Thu, 28 July 2022 19:00 UTC

Return-Path: <xipengxiao@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 0E24EC13194C for <v6ops@ietfa.amsl.com>; Thu, 28 Jul 2022 12:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYsNvtEArAM6 for <v6ops@ietfa.amsl.com>; Thu, 28 Jul 2022 11:59:58 -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 B0032C14F613 for <v6ops@ietf.org>; Thu, 28 Jul 2022 11:59:56 -0700 (PDT)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Lv0Gm4wSQz67Wb2; Fri, 29 Jul 2022 02:56:00 +0800 (CST)
Received: from fraeml712-chm.china.huawei.com (10.206.15.61) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 28 Jul 2022 20:59:52 +0200
Received: from fraeml712-chm.china.huawei.com ([10.206.15.61]) by fraeml712-chm.china.huawei.com ([10.206.15.61]) with mapi id 15.01.2375.024; Thu, 28 Jul 2022 20:59:52 +0200
From: Xipengxiao <xipengxiao@huawei.com>
To: Gert Doering <gert@space.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] Are we competitive?
Thread-Index: AQHYoi0VzAmcPXlT+U+ha/iJFvXdnq2TY7wAgAC0IKA=
Date: Thu, 28 Jul 2022 18:59:52 +0000
Message-ID: <ec68b29c62034d3e98adec9c5da45ff3@huawei.com>
References: <e4a35f0c-757a-aefa-c211-05b6015a4215@gmail.com> <YuJXbruluDmzF3RD@Space.Net>
In-Reply-To: <YuJXbruluDmzF3RD@Space.Net>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.213.128]
Content-Type: multipart/mixed; boundary="_004_ec68b29c62034d3e98adec9c5da45ff3huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/otPRaqp9qN9ASL6vnbJkSe-ZR8s>
Subject: Re: [v6ops] Are we competitive?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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, 28 Jul 2022 19:00:00 -0000

On Thu, Jul 28, 2022 at 02:51:43PM +1200, Brian E Carpenter wrote:

>> Following the ongoing discussion about "IPv6-only" and why sites are still IPv4-only, I have a question: Are we competitive?



> [Gert] This is a valid question, which I feel hard to answer for the general case.

Let me be blunt and say that IPv6 is not as competitive as we want/think.  If we are to improve, we need to have a common understanding of the current IPv6 situation, the issues and the possible solutions.  Here is my 2c for starting the discussion:

IPv6 is currently like a messy forest:
*       littered with dead trees (obsolete features/solutions),
*       smell bad (many operations & performance issues),
*       too many roads inside the forest (too many transition solutions, too many address types), not well marked (without clear solution guidelines), and fairly confusing
*       the roads are difficult to walk (complex address architecture, debatable header design, many complex solutions like source/destination address selection, ND).
This forest has 1 big advantage: plenty of O2 (addresses).  Consequently, many people avoid this forest but those really need O2 come. A small number of "grey/white wizards" (the experts) live in the forest.  They know every tree (feature/solution) well.  But they tend to focus on fixing individual trees than fixing the forest.

If we want to attract more residents to the forest (IPv6 adopters), it's more important to fix the forest than to fix the trees.  Some ideas:
*       Provide better tour guide book (i.e. IPv6 solution overviews): There are about 500 IPv6-related RFCs.  Some are obsoleted and some are conflicting.  I think we should summarizing them and providing guidelines, so that people can read fewer RFCs to master IPv6.  (e.g. the ND deployment guideline draft summarizing 30+ RFCs into 1 draft)
*       Among the many possible routes (e.g. solutions), recommend only the most popular ones (e.g. recommend only Dual-Stack, 464XLAT and MAP-T among the 10+ transition solutions).
*       Provide better road signs in the forest (i.e. solution guidelines): IPv6 solutions are almost complete.  Now it's more important to write guidelines to simplify operations than to develop more solutions.
*       Identify haphazard places in the forest, and post clear "caution" signs (i.e. identify IPv6 operations/performance issues, and provide guidelines/BCPs)
*       Enlist existing residents to share experience on how to settle into this forest (i.e. case sharing from Cisco, Alibaba etc).

BTW, upon the request of an enterprise, a few on-site attendees had a small side meeting on Monday.  Their *anonymous* opinions and future actions are summarized in the attachment for your info.  If you are interested to join the discussion and contribute, please voice up.  Thank you.  XiPeng