Re: [IPv6] SADR for MHMP is useless yet

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 21 November 2022 14:58 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B854C152717 for <ipv6@ietfa.amsl.com>; Mon, 21 Nov 2022 06:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 sjrylFM2MFgf for <ipv6@ietfa.amsl.com>; Mon, 21 Nov 2022 06:58:05 -0800 (PST)
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 D1EC9C15271C for <6man@ietf.org>; Mon, 21 Nov 2022 06:58:04 -0800 (PST)
Received: from frapeml100001.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NG9Rj2yjfz6865q for <6man@ietf.org>; Mon, 21 Nov 2022 22:55:29 +0800 (CST)
Received: from mscpeml100002.china.huawei.com (7.188.26.75) by frapeml100001.china.huawei.com (7.182.85.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 21 Nov 2022 15:58:01 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100002.china.huawei.com (7.188.26.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 21 Nov 2022 17:58:00 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.031; Mon, 21 Nov 2022 17:58:00 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Ole Troan <otroan@employees.org>
CC: "6man@ietf.org" <6man@ietf.org>
Thread-Topic: SADR for MHMP is useless yet
Thread-Index: Adj9rXnKxkWOEKksRvK7SW/xCLol2P//1OuA///B8XA=
Date: Mon, 21 Nov 2022 14:58:00 +0000
Message-ID: <d68d2a015e274602bff34a4dc9dbaf2b@huawei.com>
References: <d4282b3fc917460b8e73ceb2554e88cc@huawei.com> <FD9DBB7F-57EA-4739-A4FE-4927286777B1@employees.org>
In-Reply-To: <FD9DBB7F-57EA-4739-A4FE-4927286777B1@employees.org>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.195.33.77]
Content-Type: multipart/alternative; boundary="_000_d68d2a015e274602bff34a4dc9dbaf2bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pK9DHH0f-_hRN-ZvXXjnfbIbGFo>
Subject: Re: [IPv6] SADR for MHMP is useless yet
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2022 14:58:09 -0000

Hi Ole,

Let’s define “the simple topology”. It means that any host sees both MHMP routers on one link.
SADR would not apply here. The host should properly choose “the default router” at ND.

Let’s define “the more complex topology” that has 2 routers in a short chain: 1st router is connected directly to Carrier, 2nd the router is connected to 1st router (and host after this).
For this topology to start working with PA addresses should be some protocol on routers to split and re-distribute prefixes received from FBB Carrier. It does not exist yet (HNCP is not adopted). Hence, the second router does not have PA addresses. Hence, no need for SADR yet.

In general, PA prefixes need to be automatically propagated deeper (at least one additional hop) in the site for SADR to become needed.
SADR should follow HNCP, not vice versa. No HNCP -> no SADR, it is simple.
Hence, RFC 867<https://www.rfc-editor.org/rfc/rfc7084>8 is completely useless yet. We could not have a situation.
Of course, the lab can appoint PA prefixes manually to test that RFC 867<https://www.rfc-editor.org/rfc/rfc7084>8 is right.
It is not relevant for any production network yet.

Additionally, It is possible to mention that Mobile carrier is not capable to deliver prefix in general.
DHCP is blocked at the modem level on all smartphones.
For the mobile environment, the problem is double protected.

Hence, no need yet for the SADR. It is a far future, if ever.

Eduard
From: Ole Troan [mailto:otroan@employees.org]
Sent: Monday, November 21, 2022 4:57 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: 6man@ietf.org
Subject: Re: SADR for MHMP is useless yet

Eduard,

What was discussed here was a topology with two independent border routers and a stub router attached to them, with a stub link southbound.

The stub router has to, as far as I can tell, do SADR.
(Or other similar policy approaches to routing)

Do you see it differently?

O.


On 21 Nov 2022, at 14:32, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:

Hi Ole,

SADR is not important yet. Maybe in the far future (5+) it would become important.
It is useless for the PA case yet because it is not possible to come to this situation.
How PA prefix would be split and distributed between many routers and links on the complex site?
(something like HNCP or DHCP-PD). Automation here is mandatory, PA could be dynamic.
The need for SADR would happen only after this.

SADR is not needed in principle for other use cases: PI, NAT+ULA, NPT+ULA. Normal destanation-based routing is enough.

Eduard


Ole Troan <otroan@employees.org<mailto:otroan@employees.org>> Fri, 18 November 2022 14:52 UTC
Ted,

There are a few reasons why MHMP have failed.

1) it requires SADR routing in the intermediate routers. SNAC routers in young case
2) It leaves the choice of egress path to the hosts. Expecting every host/application to be smart enough to handle that correctly especially given the hosts on a SNAC link sounds optimistic.
3) Hosts selecting exit is often at odds with network policy.

PVDs doesn’t seem to be particularly important to the problem, but I don’t mind if you think it is.
Great if you can make MHMP happen.
It might be a distraction for this group and not necessarily something that can be limited to v6ops.

Anyway, I think this is something for the chairs/ADs.
O.