Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 24 May 2023 14:25 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 69AF6C17B337 for <ipv6@ietfa.amsl.com>; Wed, 24 May 2023 07:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 gWXQ5PLm-jH0 for <ipv6@ietfa.amsl.com>; Wed, 24 May 2023 07:25:25 -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 2E46EC17B331 for <ipv6@ietf.org>; Wed, 24 May 2023 07:25:24 -0700 (PDT)
Received: from mscpeml500001.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QRD1k4fq1z67LmL; Wed, 24 May 2023 22:23:22 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 24 May 2023 17:25:20 +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.2507.023; Wed, 24 May 2023 17:25:20 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "IPv6 WG (ipv6@ietf.org)" <ipv6@ietf.org>
Thread-Topic: next steps for draft-ietf-6man-ipv6-over-wireless
Thread-Index: AdmOCmpfkqHuz3alTCiAkcUKt+dBWQAHFowg
Date: Wed, 24 May 2023 14:25:20 +0000
Message-ID: <15206a27fc3a4f19ab8d2fae02be768b@huawei.com>
References: <CO1PR11MB4881C130988C6FF3A11B500AD8419@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB4881C130988C6FF3A11B500AD8419@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.189.200]
Content-Type: multipart/related; boundary="_005_15206a27fc3a4f19ab8d2fae02be768bhuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2Nm2mwaj5bbRSyFKF7jXnS5FiNE>
X-Mailman-Approved-At: Tue, 30 May 2023 08:18:48 -0700
Subject: Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless
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: Wed, 24 May 2023 14:25:29 -0000

Hi Pascal,
You could say at the beginning of the document that only downstream multicast is the problem for wireless.
Upstream multicast is emulated by unicast anyway - typically not a problem.

I am a little worried about the additional complexity related to the new layer of abstraction (IP Link). IPv6 is already deadly complex. This step is in the opposite direction of simplification.
But it looks like needed.

Picture for possible IP subnet to IP link to L2 link relationships would help the reader. I am strongly missing it. If I understand you:


        [cid:image003.png@01D98E64.B57D93C0]

Could you mention that SGP (Subnet Gateway protocol) is optional and needed only for the case when the subnet consists of many IP Links?

Figure 2 is misleading (probably a mistake): The IP subinterface and IP subnet should have the same set of IP Links (the picture implies different, for example, A and B).
IMHO: you need to delete the IP link reference against the IP subinterface or IP subnet.
Moreover, the picture is double misleading because the IP subnet (and IP subinterface as a result) may have many IP links (the picture implies only one).
IMHO: you need to put a set {IP link X, IP link Y, ..} against all IP subnet/subinterface.

The document is clear on what should be done when a subnet consists of many IP links - SGP protocol is needed.
The document is not clear on what should be done when an IP link consists of many L2 links (it is possible to guess by reading how it was resolved in different L2 technologies, but guessing is not a good option here).

All of the above was "nits".
But there is a principal problem that pushes me to vote against WGLC for this draft:
The promised solution for P2MP is just missing in the document - not discussed.
IMHO: P2MP is principally needed. Hence, it should be clearly discussed.
I guess what you would propose, but I am not 100% sure.

Ed/
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, May 24, 2023 9:52 AM
To: IPv6 WG (ipv6@ietf.org) <ipv6@ietf.org>
Subject: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

Dear WG:

We adopted that draft to publish it as informational; it is at the same time a state of the art, a problem statement, and an applicability statement.

The issues are clear and present, see also draft-ietf-v6ops-nd-considerations. We face customer situations where clients are not properly served because ND snooping fails to locate them all with a painful regularity. This impacts all sorts of situations, from wireless to fabrics / EVPN.

Note that This is indeed very related to the SLAAC operation and IPv4 is mostly immune. Meaning that the IPv6 experience is of more broadcasts and less reliability.

In order to progress in solving the issues raised, it makes sense to publish soon and move on. The draft has been progressing as an individual submission for a long time and it is mostly complete, IMHO. So my intent is to ask for WGLC sooner than later. To get there, reviews would be highly appreciated.

Many thanks in advance : )

Pascal