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

[Bernie Volz <[e-mail]>]

Personally, I’m not sure 07 was worth it. I don’t 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’t be that many).

The option should be defined as “does this link support address registration?” when sent by the client in the ORO list, and as “this link supports address registration” when sent by the server. It is a link, not a per server, setting.

Do we really need clients to track which servers do or do not do it? Do we want clients to just send registration to specific servers (i.e., include server id option) or just send to all.

And Ted:

The reason for this is that if you have some servers that support address registration, and some that do not, and you send an address registration message without specifying a server identifier, it's going to be processed by all servers,

A server that doesn’t understand the message isn’t going to say “oh, this is an unknown message but it has a server id option and doesn’t match my id?”. No, it will drop the message because it has no idea as to what the message is and even where options start. So, this idea is completely flawed - it will be discarded by the servers that don’t know the message (either silently or not). If address registration is administratively disabled, that is a different issue and the message should just be ignored (possibly with a log message, but see below as likely you want to limit that logging).

Keeping it simple is far better. Perhaps we should even consider that 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.

The only possible consideration for 8415-bis may be to caution servers against aggressive logging of unknown messages. After receiving more than X messages of any one unknown message code, reduce logging of that message code to at most once per Y minutes (perhaps X is 20, Y is 5m)? A server should log the total number of those messages it received in that period (Y) when logging the unknown message.

- Bernie

On Dec 4, 2023, at 5:45 PM, Ted Lemon <[e-mail]> wrote:



My only worry about this is that the draft (correctly) acknowledges that there may be more than one DHCP server and that such servers may have different answers to the registration question, but doesn't talk about the specifics of when the client decides that things have or have not changed. 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.

So I think that in fact what you're proposing here isn't quite right. Rather, the client in this case should wait as it does for Advertises. When it gets a reply that allows for registration, it registers with that server. If it gets no reply that allows for registration, then it stops registering. This behavior should be specified in 8415-bis, not in this document. 

What exactly should go into 8415-bis??? We don’t want to change any existing client behaviors and so not sure what is being proposed for 8415.

Additionally, the client should pick a server, and include the server's DUID in a server identifier option as specified in section 14 of 8415. So this is the opposite of what's currently specified. The reason for this is that if you have some servers that support address registration, and some that do not, and you send an address registration message without specifying a server identifier, it's going to be processed by all servers, so you'll get errors back from servers that don't support it and possibly multiple acknowledgments from multiple servers (maybe that's okay though?).

Anyway, I think this needs a bit more thinking.

On Mon, Dec 4, 2023 at 5:24 PM Jen Linkova <[e-mail]> wrote:

The WGLC has been uncomfortably quiet, so we've just submitted -07
(https://www.ietf.org/archive/id/draft-ietf-dhc-addr-notification-07.html" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/archive/id/draft-ietf-dhc-addr-notification-07.html)
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.
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.
Basically, as long as at least one server supports the registration,
the client will be sending messages, but it's still possible for the
administrator to turn the registration off.

Comments?

On Mon, Nov 27, 2023 at 9:32 PM Timothy Winters <[e-mail]> wrote:
>
> Hi:
>
> The authors believe this document is ready for WGLC. Therefore, the chairs
> are initiating a WGLC on this document.
>
> Please review this document and provide your comments and whether you
> support this document moving forward or not by the end of day on Monday,
> December 11th, 2023.
>
> Please see
> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-addr-notification-06" rel="noreferrer nofollow" target="_blank">https://datatracker.ietf.org/doc/html/draft-ietf-dhc-addr-notification-06.
>
> This is a Standards Track document.
>
> Thank you!
>   ~ Tim and Bernie
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/dhcwg



--
Cheers, Jen Linkova

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg