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

On Wed, Dec 20, 2023 at 11:11 PM 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).

Yes, indeed. It's just the behaviour described in -06 can lead to
oscillation, which is not a good thing, IMHO. But maybe it's OK.

> 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

I totally agree.

> - allows turning on and off notifications (assuming single/consistent situations)

So my understanding is that we have the following options on the table:
#1: 06 behaviour ("if the client sees the signals of the registration
support, the client sends it. If it receives a reply w/o the option,
it stops, until it sees the option again").
   Pros: it allows the server to turn off the registration w/o the
client disconnecting
   Cons: during the transition period, the client behaviour is
unpredictable (it might stop registering the addresses randomly, so
the operator can't rely on it until all servers support it.
#2: your proposal "once a client receives confirmation that the link
supports address registration, it sends them regardless of what future
Reply’s (or Advertises) say. Only when the client believes the link
has changed, does it clear the flag and send something
(Information-Request) with the registration option in the ORO list
when it lands at a (possibly) new location.".
    Pros: very simple. Guarantees consistent client behaviour.
    Cons: if the administrator wants to turn it off, it might need to
bounce the client's connection.

So I have a question for the group (as it would be awesome to finish
the WGLC ;): what shall the authors do? Which one to put into the
post-WGLC -08?

> Yes, it fails when there is inconsistency in multiple servers - so don’t do it or fix it quickly.

Software upgrades on the server infrastructure can take some time. I'm
sure not everyone would be happy to roll out a new release overnight
;)

> > 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



-- 
Cheers, Jen Linkova

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