RE: [dhcwg] dhcpv6-24: Rapid Commit

I too would like the Rapid Commit handling improved.

In particular:

- A client should be able to send this option always if it supports it.
- Servers that don't support the Rapid Commit or have not been configured to support it should respond with Advertise messages.
- A client that receives a Reply to a Solicit w/Rapid Commit *may* use that Reply. If it doesn't, it should send a Release.
- A client must use the normal Solicit procedure and await multiple Reply messages (and Advertises). If the client receives a Reply and doesn't use the information, it must send a Release. If the client receives no Reply messages or doesn't choose to use any, it should then follow the Advertise handling as normal.

The option does have a value at least from the server / server administrator standpoint. An administrator could select not to allow this if there are multiple servers in the configuration. If there is a single server (or single set of primary/backup type servers), a server can be configured to allow Rapid Commit.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:06 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Rapid Commit

This is a new addition relative to -23. I'm still trying to understand
what its actual value is. The current specification seems to have some
potential issues.

>    If the client has included a Rapid Commit option and is waiting for
>    a Reply message, the client terminates the retransmission process as
>    soon as a Reply message is received.

I'm not sure I understand the model for Rapid Commit. What happens if
two servers reply? I gather this isn't supposed to happen. Hmm.  It
seems like this is only useful if there is only one server, but in
general there is a need for multiple servers for
reliability/failover. So it seems like complexity that may not buy
much in practice. What is the deployment scenario where this is viewed
as must useful?

Also. This document doesn't provide guidance on when a client should
request this. Always? Seems like some guidance is needed, or you'll
get clients doing random things (not good for interoperability).

> 17.1.4. Receipt of Reply message

>    If the client includes a Rapid Commit option in the Solicit message,
>    it will expect a Reply message that includes a Rapid Commit option
>    in response.  If the client receives a Reply message, it processes
>    the message as described in section 18.1.6.  If the client does not
>    receive a Reply message, the client restarts the server solicitation
>    process by sending a Solicit message that does not include a Rapid
>    Commit option.

So, if the client sets the Rapid Commit, because it is in a hurry, the
process may actually take *longer* because some servers won't respond
unless the Rapid Commit is not present? This seems like a disincentive
to using the mechanism, as it might not only be quicker, it might
actually be longer, and there isn't a way for the client to know
without just trying. Right?

Also, section 18.1.6 does not  include any text about the Rapid
Commit. So, what does a client do with a response that does include
it? Doesn't include it?

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg