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

The gap I see in 8415 is that it doesn’t allow for multiple servers
answering the information request with different answers. But as you say,
maybe that’s okay. Maybe that’s a misconfiguration and so we should just
say so rather than doing protocol work to adapt to it.

Op ma 4 dec 2023 om 20:00 schreef Bernie Volz <[email protected]>

> 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 <[email protected]> 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 <[email protected]> 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
>> )
>> 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 <[email protected]> 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
>> .
>> >
>> > This is a Standards Track document.
>> >
>> > Thank you!
>> >   ~ Tim and Bernie
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> dhcwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

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