From furry13@gmail.com Tue Oct 10 23:24:20 2023 Return-Path: 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 B89A0C14CE40 for ; Tue, 10 Oct 2023 23:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZtJOLklnJxxK for ; Tue, 10 Oct 2023 23:24:16 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CD7C14CEFE for ; Tue, 10 Oct 2023 23:24:16 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2c00e1d4c08so83129211fa.3 for ; Tue, 10 Oct 2023 23:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697005454; x=1697610254; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mufGWtSMp70A9mREbhMNy2C9OBlMXtRiyX74ePCB/A4=; b=Lpc/HVAPTyUB9oR6Ey0P94u4O7dDNPdf/BWOKQNXWcWpS8BSLhEnaHAGQshID+2blP iItMKLYXJrwMxUc7eWxqyhDtsH7OA6lu5+cXcp8XpoKCoJOyZM5FPNujUYVQIVCm2120 IMOKyj/y9QqEbaQ08bgBsML0BaQGCzxl93L/sUdafh/W4JXOeC3fA5NsptA/IvZ3Vfw8 g8FXunxmHK0l4UlP1uh/S3f8b39yYxvFHkKtIk2c9/U+/zwGeJmQMS0DfJ2oJsp8f7e5 vO4/FYSkGUrwYkBj7HOJeViLxGNlrhvn3+a/zojiLOykhgp0FjlflictWJUbHoMi/a3c J6aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697005454; x=1697610254; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mufGWtSMp70A9mREbhMNy2C9OBlMXtRiyX74ePCB/A4=; b=JXhooe+b0uNPVCI1fMKhWf7J3uu7TA5BYYy5zPqrtGQXifOt+A+dfnyCtrNBlePh2M xOPZXvnq4cXZSTo9M1BiwDiMYLYYSH7DLi33Ae2EinOgOigrOOcwNvk39/HBMECsqEdi hMX2hEbhjYNRWAXTRqNPNmgWV1ZvyQlLMcTMqmdoxk7B79c0gI5yuZt5EdzJeEOxPlcQ mwgCTI/FIb4n3YnAz0fI1YHyanM25zaFlI59I1n1hNxQo/jUIXf6RKFON5VNsYt9Co5z opbU4Zsr1VnXwPpoe3qAzF0zlG7nuOL9DmNEYnFetmu+XRsx9AQD5/6+fppPVuy245gx oT9A== X-Gm-Message-State: AOJu0Yx5BWfENbmvjxlPpC821RSMRL0rk+6i9UU+mi7jWSStrVt+yUNV LVP+dPL5Wp4IyjS2vDOeCQMPV0JqWjya5+Z3SS2GRPg9 X-Google-Smtp-Source: AGHT+IEy+ZvhM+tAtWoKzBwF/fxofJe/DzcU//DTtQSfDgSaLdeTwG5fn6YJ9be/SyM1bw5ItQEUFNzC6kpJTarnuec= X-Received: by 2002:a2e:8ed9:0:b0:2bc:d5ad:2758 with SMTP id e25-20020a2e8ed9000000b002bcd5ad2758mr16327827ljl.5.1697005453458; Tue, 10 Oct 2023 23:24:13 -0700 (PDT) MIME-Version: 1.0 References: <169660647031.23597.13067349132781805398@ietfa.amsl.com> <2AE8C0BD-4290-45B2-82A6-7DE89BBD6EAD@employees.org> <6BCFB0B4-2C37-4A9F-9437-FAA60E8A784E@employees.org> In-Reply-To: <6BCFB0B4-2C37-4A9F-9437-FAA60E8A784E@employees.org> From: Jen Linkova Date: Tue, 10 Oct 2023 23:24:02 -0700 Message-ID: To: Ole Troan Cc: Lorenzo Colitti , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2023 06:24:20 -0000 Hi Ole, On Mon, Oct 9, 2023 at 11:36=E2=80=AFPM Ole Troan wr= ote: > > On Tue, Oct 10, 2023 at 3:10=E2=80=AFPM Ole Troan wrote: > > > This is very similar to how address pools are allocated when using DH= CP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), where eac= h link has a dedicated pool of addresses, and clients on the link obtain ad= dresses from the pool. In this model, each link's pool can be sized accordi= ng to the expected maximum of devices on a particular link, similar to how = DHCPv4 pools are sized today. For example, if the network assigns a /64 to = every client, then any link that is assigned an IPv4 prefix of /X (e.g., X= =3D/18, X=3D/24) would require a corresponding prefix pool of size X+32 (e.= g., X=3D/50, X=3D56). > > > > I think I would like to see some operational guidance. > > > > Isn't the text I suggested above already operational guidance? It basic= ally says that for the pool-per-link model (which is the only one documente= d in the draft), the operator should assign one pool for each link and size= the pools based on expected maximum usage, which is basically the same way= that operators size IPv4 address pools today. Not sure what else we should= say here, maybe say that the lease times need to be consistent with IPv4 l= ifetimes as well, to prevent prefix exhaustion? > > Yes, lifetimes as well as T1/T2 timers. > It would probably be good to not say consistent with IPv4 timers, as we= =E2=80=99d like the text to be applicable in an IPv6 only context. This is very much similar to how operators choose DHCPv4 lease timers nowad= ays. Maybe we can just say smth like: "As most operators have some experience with IPv4, they can use the similar approach for choosing the pool size and the timers (such as T1/T2 timers). In particular the following factors shall be taken into account: - the expected maximum number of clients; - average duration of a client connection; - how mobile the clients are (a network where all clients are connected to a single wired VLAN might choose longer timers than a network where clients can switch between multiple wireless SSIDs); - expected level of recurring clients (for example, a corporate authenticated WiFI network might be using longer timers than an open public WiFi)." I do not think we can recommend specific values as there is no "one size fits all" solution. What do you think? > This document should be in sync with (and probably should reference the s= tub router document. > At least there should be text explaining the two models. Flat and hierarc= hical. And that the network needs to support both. I think it's not possible to support an arbitrary number of clients with an arbitrary number of networks (flat or hierarchical) behind them (unless we have truly unlimited resources). I believe the goal of this draft is to document what can be expected to work and what is a "nice to have" extras. So I have a suggestion. How about this: - we clarify in the Applicability and Limitations section that the proposed solution supports expanding the network to at least one interface behind a client, and it MAY support more - depending on the network policy and resource availability. - in the Prefix Length consideration section, we'll add a reference to the draft-ietf-snac-simple as another example (thanks for the reference, btw!) -- SY, Jen Linkova aka Furry