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

* “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 <[email protected]> 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 <[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
>

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