Re: [v6ops] draft-yu-v6ops-split6 question

hsyu <hsyu@cfiec.net> Thu, 24 March 2022 02:59 UTC

Return-Path: <hsyu@cfiec.net>
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 4B0133A1165 for <v6ops@ietfa.amsl.com>; Wed, 23 Mar 2022 19:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.226
X-Spam-Level:
X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 1nprm3mtiajM for <v6ops@ietfa.amsl.com>; Wed, 23 Mar 2022 19:59:26 -0700 (PDT)
Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) (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 5D8B93A1160 for <v6ops@ietf.org>; Wed, 23 Mar 2022 19:59:24 -0700 (PDT)
X-QQ-mid: bizesmtp86t1648090758tniqj2xa
Received: from DESKTOP-3U2VLEE ( [124.14.224.58]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 24 Mar 2022 10:59:13 +0800 (CST)
X-QQ-SSF: 00400000002000B0C000B00A0000000
X-QQ-FEAT: KUZf+4ohqx6g5Q3xk/UlByq5DhP/N9y99Re+o0ur1qrlRVDG4AzbN9qc5biGr R1X4MoiIHQPYjcQHULXm806HbKM1LJbpmqW6M71yjPev2f8jHemuiqcBt9deHRCjq3FiVhG SGQnv+sOvulx5lSvv4HuLDKUktYNTe314lcKgEPMs6824iZu/oFQxuX35MtrrSnDMfgmx85 yQ6gl4J7aHVG3ulqVlVI/TWhO7VTSSKvzI8Z291w6ly6rTFo0lNJJoqjbX1ECbbadnzkbLo rrDgBGG1XsEIV0Lqmb7cpfvyQnmg0fZ6PS6Myk/slpBxrLKX3ocrT0nfE3WdR5ZHZ9nDRK0 tJ1EEZv
X-QQ-GoodBg: 2
Date: Thu, 24 Mar 2022 10:59:12 +0800
From: hsyu <hsyu@cfiec.net>
To: "brian.e.carpenter@gmail.com" <brian.e.carpenter@gmail.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <D9996756-B6CA-43EC-AF32-96B3A27D2E19@cfiec.net>
In-Reply-To: <b3774890-f4ab-0e4e-55a4-cde810baa769@gmail.com>
References: <164782815040.16661.10557347152889564572@ietfa.amsl.com> <AAEC2F11-3BD7-41B9-A384-B47854613591@gmail.com> <0768760E-B28B-4C11-A5E9-1476B4425DEA@employees.org> <D7335352-3A25-4E70-9DE9-23967EAC7E31@cfiec.net> <YjhECZfPCdempLxQ@Space.Net> <b3774890-f4ab-0e4e-55a4-cde810baa769@gmail.com>
X-Mailer: MailMasterPC/4.16.1.1026 (Win10 19H2)
X-CUSTOM-MAIL-MASTER-SENT-ID: 4374B05E-DCFE-475D-A530-CD99A1557166
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:cfiec.net:qybgforeign:qybgforeign3
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/MtqGd7SD4d_GCktLexU0ogYX5yI>
Subject: Re: [v6ops] draft-yu-v6ops-split6 question
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, 24 Mar 2022 02:59:31 -0000

Dear Brian

         My idea is not to fix the route without changing, long CIDR can ensure that the route is more accurate, so it can be routed to the destination faster, which is very necessary. But considering the bottleneck of the routing device and the speed of finding routes, the aggregation of routes is necessary. We know that the number of routing entries is positively related to the number of networks. The more networks there are, the more routes there must be. What we expect is that network changes that occur in a short period of time (such as a month) do not affect changes in the number of networks and changes in the number of routing tables. This is the most fundamental reason for me to consider doing this draft.

         Best regards.

On 3/24/2022 10:17Brian E Carpenter<brian.e.carpenter@gmail.com> wrote:
We've had this discussion before, I thought.

https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6 makes the opposite argument. It wasn't strictly speaking necessary to make the argument at all, because BCP 198 (RFC 7608) settled the question.

Brian
On 21-Mar-22 22:23, Gert Doering wrote:
Hi,

On Mon, Mar 21, 2022 at 04:42:55PM +0800, hsyu wrote:
</span></div><div><span><br></span></div><div><span>I think with the development of IPv6, the location and separation of IPv6 addresses is an issue worth discussing, such as:<br>By separating location and identity, a robust routing table can be achieved, reducing the risk of route explosion.<br>Let the routing address work in the routing space, and let the identity domain work in the identity space. Ensure easier routing and easier and more accurate authentication.</span></div>

While this sounds really nice, I have a hard time understanding how
this would be achieved.

Mandate aggregation of routes?  To what level?

Disallow IPv6 PI space?

How would DNS look like, how would "small enterprise" multihoming look like?

Gert Doering
-- NetMaster


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops