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

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 <[email protected]> wrote:
> 
> On Tue, Dec 5, 2023 at 7:08 PM Michael Richardson <[email protected]> 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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg