Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023

[Jen Linkova <[e-mail]>]

On Tue, Dec 5, 2023 at 7:08 PM Michael Richardson <[e-mail]> 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 <[e-mail]> 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