Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023
Li HUANG <bleuoisou@gmail.com> Wed, 20 December 2023 23:54 UTC
Return-Path: <bleuoisou@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAEFC15152D for <dhcwg@ietfa.amsl.com>; Wed, 20 Dec 2023 15:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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
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 uJnRyBWyQYKm for <dhcwg@ietfa.amsl.com>; Wed, 20 Dec 2023 15:54:51 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 61828C15107F for <dhcwg@ietf.org>; Wed, 20 Dec 2023 15:54:51 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id 46e09a7af769-6dbb7d80df8so7545a34.1 for <dhcwg@ietf.org>; Wed, 20 Dec 2023 15:54:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703116490; x=1703721290; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PAe5AoZAC9/HtxIPmGUmHE2/VNxOCuu0FdXHqnxRPno=; b=ftjSvbB3KMbxjHdrKiyGxMMxicTRdEb0ttYk97wsb7KI+W6Gr57xCJc9K/D83DZ4hd 6Aw7b+N6up+RSqVGOg2Hf3b6pGKreTzQWVv+Vpkm+b3KY6JmReUonzfRsx6jr4sVbfPu ueDvBjLuk48nKqEzsG50sSrj/hfauWibI6qj/Poy0B58weFalhhEdlhjGLIMviND0oSq rt/zhBQwaOfrBxO0KRn9r0GTrmntwAlklNxnOEyMHB2bdhlGdPTAKPUAk0bjJTOa0wQn 2B4t6AuhjXHzSHlXnnyMSysw+7fpJi5Xs6sOCmJogILHscx1KeOt6gsspiE6LHOxXqSy xEzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703116490; x=1703721290; h=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=PAe5AoZAC9/HtxIPmGUmHE2/VNxOCuu0FdXHqnxRPno=; b=bIrBhbHFib3/63IjgELOOtC2kUIhg2OPmupebHC8uXcoFwX5agPb34fdJ/mdsF9Q7Q n8AzHona3/KNTArQDaeMryFAqdb3GDcKTlFVvD5PTKAaIKEAPkRmMv9Jt8eRCMVWqKhA aUeggnrh1fZ9+U0yPffXYvBu6uEzZb79Lv+ex1RPSuD93MzkM0MIt92joO0RT/a2J6JC RgIG0pNTJRJ5MSYghQYXDv7SlcyjL3PxFtiDYJt+mGQDT72qcwM1U5WklEUP+z3Aqw/o y/rpvVBqpOV41/K9v/l+YcXNe3W2R4eSsrlWlOHll9yuhAcGFNMJFfu8OB5nk7Acwmyu vl5w==
X-Gm-Message-State: AOJu0YyRXETV3/tio2W65c2Z3iAQ8zRii3yuXeZs0HPqMQucn0BOcgkW JL7/uNA993Dr19W95/Wo9Nx8o4vhV/SCdVuMzgSov31nIrs=
X-Google-Smtp-Source: AGHT+IFUxm78chgmrEaBsesmKlXOAGfTAfZq/lkYzv4bf14mWmXrQvLq7zo2OYpezmcnQkdBsEMhBQ04magjKyPKOR0=
X-Received: by 2002:a9d:76cb:0:b0:6d9:d54e:a409 with SMTP id p11-20020a9d76cb000000b006d9d54ea409mr18583386otl.61.1703116490283; Wed, 20 Dec 2023 15:54:50 -0800 (PST)
MIME-Version: 1.0
References: <CAFU7BAQ1Ge3yKjdSXEX80ukbw-OYMReC8+Tvh6UNAB2UKEOz5w@mail.gmail.com> <9A5C6A10-0691-4F28-92DE-83EC6BF93077@gmail.com>
In-Reply-To: <9A5C6A10-0691-4F28-92DE-83EC6BF93077@gmail.com>
From: Li HUANG <bleuoisou@gmail.com>
Date: Thu, 21 Dec 2023 07:54:40 +0800
Message-ID: <CAGGiuEbu34ZLO4obD8jTQOhXvvjGz9h16sByA43NP2O9fDBeHQ@mail.gmail.com>
To: Bernie Volz <bevolz@gmail.com>
Cc: Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006a1de6060cf9b51b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/YraruuLKebClIY7vrYVsCm8SOR0>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2023 23:54:56 -0000
* “servers - so don’t do it or fix it quickly”* *Either way at EEE or server areas before ,all end user the world being collected to be bypassed on rfc2119 from 1996 no feedback .* On Thu, Dec 21, 2023, 06:11 Bernie Volz <bevolz@gmail.com> wrote: > My point for originally raising this issue was just to point it out in the > draft to make operators aware of the issue when there are inconsistently > configured servers. I don’t think I had an issue with was proposed (before > 07). > > I think keeping it very simple: > - makes coding and testing much easier > - works well when there is a single server or multiple consistently > configured servers > - allows turning on and off notifications (assuming single/consistent > situations) > > Yes, it fails when there is inconsistency in multiple servers - so don’t > do it or fix it quickly. > > - Bernie > > > On Dec 20, 2023, at 3:58 PM, Jen Linkova <furry13@gmail.com> wrote: > > > > On Tue, Dec 5, 2023 at 7:08 PM Michael Richardson < > mcr+ietf@sandelman.ca> wrote: > >>> to address an oscillation problem: if some servers support the > >>> registration and some don't, the client might turn the registration on > >>> and off, depending on the order of arriving Replies. > >> > >> We can all agree that it's a mis-configuration, but I hope we can also > agree > >> that it shouldn't keep the client from doing it's thing. > > > > So we are all in agreement that if at least one server signals > > registration support, the client shall start sending registration > > messages. > > The main question we have is when to stop (if stop at all). > > > >> The broken servers > >> are... broken, and perhaps an automatic configuration process will > update > >> them in a few minutes or hours. (Why break all your servers at the same > >> time!) > > > > Yes, so maybe we shall not introduce additional complexity to the > > client implementations to save some multicast traffic during the > > transition period or if the server is misconfigured. > > > >>> While it's not the end of the world, I think it's rather undesirable. > >>> The new text says that the client always register if at least one > >>> server returns the OPTION_ADDR_REG_ENABLE option, and say the client > >>> MUST stop > >>> registering if that server stops returning the option. > >> > >> I wanted this text, and I continue to want it. > > > > So the problematic part is about stopping those messages. > > I see the following options: > > 1. The client does not stop at all as long as it's connected to the > > given link (Lorenzo's suggestion). > > 2. The client sends an Information-request periodically, wait > > for....how long?...(the shorter of RT and MAX_WAIT_TIME as per section > > 7.6 of RFC8415?) and continue retransmission as long as at least one > > reply allows that. my understanding that this is a grey area in > > RFC8415 anyway, so might not be the best option. > > 3. (introduced in -07 and it looks like the group doesn't like it): > > described above > > Any other suggestions? > > > > Maybe the client shall stop transmitting if it doesn't receive an > > explicit signal of registration support for 3 X > > information-refresh-time? > > > >>> The only message for which RFC8415 acknowledges that there can be > multiple > >>> replies is a Solicit, but in fact an Information-Request could just as > >>> easily return multiple replies. I don't know if the WG is thinking > about > >>> this, but this seems like a fairly serious gap. > >> > >> I guess I don't have enough experience with Information-Request > messages to > >> understand this situation. I thought they were all unicast. > > > > I believe all traffic sent by the client is multicast (RFC8415 allowed > > the unicast option but it's being deprecated in the -bis; > > > https://www.ietf.org/archive/id/draft-ietf-dhc-rfc8415bis-03.html#name-reception-of-unicast-messag > > > >> Bernie Volz <bevolz@gmail.com> wrote: > >>> Personally, I=E2=80=99m not sure 07 was worth it. I don=E2=80=99t > think having the > >>> clients track the servers is worth doing. And if the network conflicts > >>> in the setting, live with it - fix the settings on all servers (there > >>> shouldn=E2=80=99t be that many). > >> > >> okay, I generally agree. > >> While it might be rare for an enterprise to deploy DHCP servers from > >> different vendors (and therefore different feature sets), I'll bet it's > not > >> rare for them to incrementally upgrade the servers, with significant > gaps > >> between the upgrades... because critical infrastructure. Particularly > if > >> it's integrated into some AD server. > > > > The question is how much complexity we'd like to introduce to cover > > that case (especially as it's not really harmful, just some servers > > receive messages they do not support). > > > >>> It is a link, not a per server, setting. > >> > >> I don't think that I agree, but I could live with this. > > > > As the client always sends traffic as multicast, it's effectively > > per-link, I agree with Bernie. The client either sends those messages > > on that link, or not. > > > > -- > > Cheers, Jen Linkova > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >
- [dhcwg] WGLC for draft-ietf-dhc-addr-notification… Timothy Winters
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Lorenzo Colitti
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Li HUANG
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Lorenzo Colitti
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ivan A Pena
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ole Trøan
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Lorenzo Colitti
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Li HUANG
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson