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

[Bernie Volz <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg