Re: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 09 October 2023 08:24 UTC

Return-Path: <vasilenko.eduard@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 6235CC151077 for <v6ops@ietfa.amsl.com>; Mon, 9 Oct 2023 01:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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, 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 FvPRG4ZBiAWK for <v6ops@ietfa.amsl.com>; Mon, 9 Oct 2023 01:24: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 10511C151090 for <v6ops@ietf.org>; Mon, 9 Oct 2023 01:24:49 -0700 (PDT)
Received: from mscpeml100001.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4S3sV36gswz6K5t8 for <v6ops@ietf.org>; Mon, 9 Oct 2023 16:22:51 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100001.china.huawei.com (7.188.26.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 9 Oct 2023 11:24:45 +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.031; Mon, 9 Oct 2023 11:24:45 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Jen Linkova <furry13@gmail.com>, V6 Ops List <v6ops@ietf.org>
Thread-Topic: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03
Thread-Index: AQHZ+GyzlZLLKFsbPEOpBI4KPNu3tbBBFwZQ
Date: Mon, 09 Oct 2023 08:24:45 +0000
Message-ID: <4b3c4f31428f4d0e8e6140b142899e9e@huawei.com>
References: <169660647031.23597.13067349132781805398@ietfa.amsl.com> <CAFU7BATORG5sruy19XMAXsfvqumOB7wL=G1EbNo-zUrtzoddNg@mail.gmail.com>
In-Reply-To: <CAFU7BATORG5sruy19XMAXsfvqumOB7wL=G1EbNo-zUrtzoddNg@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.56.242]
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/v6ops/R6GcMw9v9AdVT-wNSNTpc_sT1T4>
Subject: Re: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03
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: Mon, 09 Oct 2023 08:24:53 -0000

Hi Jen,

I would put myself in an obstain position on the WGLC voting.
From one point of view, it is already a good step in the extension of use cases footprint:
"Note that assigning a prefix of sufficient size to support SLAAC does not require that subtended nodes use SLAAC; they can use other address assignment mechanisms as well."
But from another point of view, section 8 makes a good attempt to motivate that "never-ever longer than/64 for sub-delegation because SLAAC may be behind".
DHCPv6 or Local Algorithm (for Container) may be behind then /64 is not mandatory at all.
Fortunately, the current text does not block such an opportunity.

Draft readability has become very good.

You have lost the comment from Ole: "Why Broadcast network? Any special meaning?".
I propose to delete "Broadcast" in the draft title.
Subnet could be small but the document may be applicable anyway. It is up to the network owner.

If you preserve "broadcast network", it is better to replace it with "broadcast subnet".
Because "Broadcast network" is something different: https://en.wikipedia.org/wiki/Broadcast_network

Eduard
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova
> Sent: Friday, October 6, 2023 6:48 PM
> To: V6 Ops List <v6ops@ietf.org>
> Cc: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
> Subject: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03
> 
> Dear v6ops WG,
> 
> We have just submitted the -03 version for
> ietf-v6ops-dhcp-pd-per-device - thank you very much to everyone who
> provided feedback!
> Please review and let us know if the draft is ready to progress.
> 
> The main changes:
> - Introduction is rewritten (much shorter and, hopefully, more clear)
> - some text about multiple addresses use cases moved to Appendix.
> - The Applicability and Limitation section is moved up, so it's in the
> beginning - hopefully it would help the readers to understand what
> scenarios are in scope and what are not.
> - Client Mobility section added to discuss what happens when a client
> moves between network attachment points.
> - the draft is now explicit that it focuses on "a pool per link"
> scenario, which also drastically simplifies the routing and relay
> requirements (the routing section is updated as well).
> - the draft now suggests Active Leasequery as one of the mechanisms to
> keep the relay state in sync with the server.
> - The Prefix Consideration section has been updated and states that
> the endpoints are not required to use SLAAC - it's just the network
> allows them to do that, if they need to.
> - various changes to address other comments received during the WGLC so
> far.
> 
> I'd like to ask everyone who has expressed concerns during this WGLC
> (you are in Cc: - hopefully I didn't miss anyone) to review the new
> version and let the author know if you still have concerns.
> 
> Thank you!
> 
> On Fri, Oct 6, 2023 at 8:35 AM <internet-drafts@ietf.org> wrote:
> >
> > Internet-Draft draft-ietf-v6ops-dhcp-pd-per-device-03.txt is now available.
> It
> > is a work item of the IPv6 Operations (V6OPS) WG of the IETF.
> >
> >    Title:   Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large
> Broadcast Networks
> >    Authors: Lorenzo Colitti
> >             Jen Linkova
> >             Xiao Ma
> >    Name:    draft-ietf-v6ops-dhcp-pd-per-device-03.txt
> >    Pages:   18
> >    Dates:   2023-10-06
> >
> > Abstract:
> >
> >    This document discusses an IPv6 deployment scenario when individual
> >    clients connected to large broadcast networks (such as enterprise
> >    networks or public Wi-Fi networks) are allocated unique prefixes via
> >    DHCPv6 Prefix Delegation (DHCPv6-PD).
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device-
> 03.html
> >
> > A diff from the previous version is available at:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-v6ops-dhcp-pd-per-
> device-03
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops