Subject: Minutes of 3rd and last Failover conference call

From: Kim Kinnear <[email-masked]>
Date: Mon, 18 Oct 1999 16:59:13 -0400 (EDT)

Last Thursday, we held the last of three conference calls
concerning the current failover protocol draft.

This last meeting was reasonably well attended, and we
considerable progress.  Thanks to all of you who attended this
call.  The roster of attendees is at the end of this mail, as is
a list of action items for people from the various calls.

Cheers -- Kim

--------------------------------------------------------------

Minutes from the 10/14/99 Failover conference call.

The last failover conference call again had good attendance, though some
couldn't make it for this call.  The agenda was to discuss Dynamic DNS
and how it should be handled by a failover servers.  We added several
additional agenda items: how to handle pinging by failover servers,
reservations and dynamic BOOTP and failover, and how to get the draft
revised by the deadline.

Old Business
------------

I forgot to put in the minutes from the 2nd failover conference call
that I would be collecting "interesting" scenarios for the failover
protocol, and would try to respond to them as to how the failover
protocol will handle them.  If, at some point, someone wants to edit
them into an informational draft, I'll give them everything I've save.
Perhaps I will get to it before someone else does.

Dynamic DNS and Failover
------------------------

Mark Stapp (the current lead author of the DHCP-DNS draft) kicked off
the discussion of dynamic DNS and failover by discussing the approach in
the -04 failover draft, and proposing a change.  His proposal was to not
use a re-constituted version of the client-fqdn option (described in the
DHCP-DNS draft) but rather to use a special purpose option which carries
just the information required by two failover servers.

Mark asked which server writers used Dynamic DNS, and got back the
following list of people (I think -- please correct me if I'm wrong):

Rob Stevens
Richard Jones
Bernie Volz
David Erdmann
Alok Joshi
Andre Kostur
Mark Stapp

Rob Stevens then suggested that dynamic DNS was just another
complication in the failover draft, and that we should handle it in
another draft that could be associated with the failover draft.  After
some discussion on this topic, Kim Kinnear asked for a virtual show of
hands for people that agreed with Rob, and didn't find anyone else that
thought that we should move the integration of dynamic DNS and failover
off to a separate draft.  Rob suggested that at least the use of dynamic
DNS options should be a MAY in the draft and not a SHOULD.  Kim
suggested that we see what the actual support requires and then deal
with that question after the next revision.

We then talked about what the general nature of support for dynamic DNS
would look like, yielding the following general rules:

     1.  When a server gets a name from a client and intends to do
     dynamic DNS updates, it should send the information to its partner
     in the new option that Mark will specify.  It can send this
     information before it does the DNS add and again after, or just wait
     until it has done the DNS operation and send it after.  The option
     has flags to indicate whether the operation has been completed or
     not.

     2.  A server doesn't do a DNS operation on an expiring lease unless
     that server is responsive to that DHCP client (e.g., a secondary
     server doesn't do DNS operations if it is in NORMAL state).

     3.  A server MUST NOT remove a name from DNS until a lease becomes
     available to the server to reallocate to another client.  Thus, when
     a server enters partner-down state, it doesn't remove a DNS name for
     a lease when the lease expires, but only after the lease expires and
     the MCLT has passed beyond expiration (which is when the lease also
     becomes FREE).

     4.  A server can allow the client to process its on DNS A record or
     not, but it must communicate that as part of the DNS information to
     the other server.

Kim brought up the issue about servers that can be configured to support
the "first name wins" strategy of dynamic DNS, where the first DHCP
client to present a name gets that name, and later clients get a
different name (known by some as a disambiguated name).  In this style
of dynamic DNS support by DHCP (which is only one of the several styles
listed in the DHCP-DNS draft), it is important for the server to be able
to detect when the client's name changes.  In order to detect this, the
server must keep the name that the client originally presented as well
as the name that the server put into DNS for the client.  If this is to
work over failover, the server who puts the name into DNS must send
*both* names to the other server.  Kim proposed an extension to the new
DDNS option that Mark will propose to hold this information.

Bernie Volz then suggested that a generalized extension to the failover
protocol could be used to solve this (and other) problems.  The
generalized extension would be a container-style option (reminiscent of
the vendor-supplied-options option) could be used to send over to the
failover partner all of the "interesting" options that the DHCP client
sent in.  This could include the host-name or client-fqdn option,
solving Kim's problem of sensing the name change, but also it could
include the relay-agent-option (among others), in a general way.

Kim said that, following that line of thought, what about another
container which would include the "interesting" options that the DHCP
server sent to the DHCP client (e.g., the renewal and rebinding times
are something that can't directly be calculated with any certainty by
the partner server, since in a failover server they are based on
knowledge of what the partner server knows).  Bernie said sure.

After some discussion, we agreed on two new options, one for the
interesting client input options and one for the interesting client
output options.  The list of *interesting* options would be given and
refined over time in the draft, and new options would be requested to
define if they were "interesting" to a failover partner server.
All of this would be a SHOULD or MAY in the draft.

The format of the options in the container was discussed, and we decided
on a format similar to the options area, with a magic-number as the
first 4 bytes, and then a free-form options area.  This way, can support
the older ?R5?  options as well the newer ?R6?  expanded style options.

Bernie said that a binding update only sends difference information, as a
response to Kim's question as to whether a server had to save all of the
incoming DHCP client options forever to as to be able to send them in
every binding update.  Kim agree with Bernie that you didn't have to
send them every time, and that he would update the draft to indicate
that binding updates only send different information.

Rob brought up what about a failover partner that sends the these
options for a while and then stops -- that would be allowed by a MAY or
SHOULD in the draft.  Ralph Droms discussed the general sense of what a
MAY or SHOULD should mean.  Mark read us the exact words from the
defining draft, and Kim agreed to put some text in the failover draft
suggesting that a server might or might not send these options, but that
it SHOULD be consistent in doing it one way or the other (at least
without configuration information to the contrary).

With these additions to the general protocol, Kim said that his issue
with name change determination was solved.

The last discussion was about when should a failover partner B do a DNS
update when it notices that it wasn't done by the other server A and
when B becomes responsive for those clients.  We identified two
approaches:

     1.  Begin to update all dynamic DNS names that are not listed as
     currently up-to-date as a sort of background process.

     2.  Update dynamic DNS names upon next client contact if they are
     not listed as currently up-to-date when a client next renews.

Either would be acceptable.

Pinging by Failover Servers
---------------------------

Rob Stevens brought up the issue of pinging by DHCP server, and what to
do with this issue in a failover context.  Kim mentioned that there is a
special state (ABANDONED) in the failover draft which is used to
communicate that a server has determined that an IP address is in some
sort of unrepairable state and should not be used.

Rob discussed what server do when pinging in general, and most (some,
many?) server writers agreed that when a client DISCOVER's and it
already has a lease for an IP address, that they don't ping.  Rob
mentioned that at one point they didn't do that -- i.e., they *did*
ping, but that turned out to be a problem for both DISCOVER's, but even
more so for BOOTP requests that were handled as dynamic BOOTP requests.

Generally, from a failover standpoint, pinging only when an IP address
was currently believed to be unused by any client was considered a good
idea.

However, this topic caused Kim to bring up reservations and dynamic
BOOTP and failover.

Reservations and Failover
-------------------------

Reservations are a situation where a particular IP address is "reserved"
for only a specific DHCP client.  The client still uses DHCP, but gets
only a particular IP address whenever it DISCOVER's.

In a traditional two server DHCP environment, each server has to have a
disjoint set of addresses for allocation, except that they have to have
*identical* lists of reservations.

In a failover situation, each server needs to be able to hand out a
reserved lease.  Kim discussed one approach, which is to have each
server see these IP addresses as available locally.  While this can
work, Bernie suggested that perhaps a new state of FREE-RESERVED might
be used to indicate a reserved lease.  This is fine, but it gets lost as
part of the normal lease process.

One approach is to simply have each server to "know" which leases are
reserved -- and that is fine, but there are synchronization holes if a
reservation is made while the servers are running, and they become aware
of the new configuration (i.e., the new reservations) at different
times.  Kim said that he would try to handle this in the revision of the
draft, and people could see how they liked it.

Dynamic BOOTP and Failover
--------------------------

Kim also brought up the dynamic BOOTP case, and mentioned that the only
way that he had seen to handle it was to never actually use the other
servers IP addresses, even in partner down, when using a range of
addresses that support dynamic BOOTP.  The reason for this is that
"BOOTP is forever", and that the MCLT has no meaning in a situation
where a server is doing dynamic BOOTP.

In this case, there are obvious benefits to sequestering the addresses
available for dynamic BOOTP in a small address range.

How to get the next draft completed:
-----------------------------------

Kim said that this was the list (moderately large) changes scheduled for
the next draft revision (-05):

1. Security section: Bernie Volz (received as of 10/18).
2. SASL information: Ted Lemon.
3. DDNS option proposal: Mark Stapp.
4. Conflict Resolution proposal: Kim Kinnear.
5. State transition diagram for IP addresses: Kim Kinnear.
6. New failover endpoint state for communications interruption during
conflict resolution: Kim Kinnear.
7. How to handle reservations proposal: Kim Kinnear.
8. Information on how to handle dynamic BOOTP: Kim Kinnear
9. General updates (many small ones): Kim Kinnear

----------------------------------------------------------

The attendees at this meeting were:
  
Tawei Chen        Merrill Lynch       EDT   [email-masked]
Ralph Droms       Bucknell U.         EDT   [email-masked]
David Erdmann     Nortel Networks     EDT   [email-masked]
Steve Gonczi      Process Software    EDT   [email-masked]
Todd Goodyear     Merrill Lynch       EDT   [email-masked]
Richard Jones     Checkpoint Software PDT   [email-masked]
Alok Joshi        Merrill Lynch       EDT   [email-masked]
Kim Kinnear       Cisco Systems       EDT   [email-masked]
Andre Kostur      Incognito           PDT   [email-masked]
Diana Lane        Wal-Mart Stores     CDT   [email-masked]
Greg Rabil        Lucent Technologies EDT   [email-masked]
Harry Roberts     Merrill Lynch       EDT   [email-masked]
Mark Stapp        Cisco Systems       EDT   [email-masked]
Rob Stevens       Join Systems        PDT   [email-masked]
Bernie Volz       Process Software    EDT   [email-masked]