Subject: Minutes of today's Failover conference call

From: Kim Kinnear <[email-masked]>
Date: Tue, 5 Oct 1999 17:12:11 -0400 (EDT)

Today we held the first of two (or possibly three) conference calls on
the current failover draft.  The attendees list is below, as are the
minutes of the meeting.

The next call is 12pm, Thurs Oct 7, 1999.  If you are interested in
participating, please let me know and I'll send you contact information.
The agenda for that call is: conflict resolution, initialization, and
state transitions.

Thanks to all of you who participated in today's meeting, it was
unusually productive!

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

Minutes of 10/5/99 Failover draft conference call/meeting:

There were three primary agenda items covered in today's failover
conference call, Implementation using TCP, Loadbalancing, and Security.
Below you will find a brief summary of the minutes of this meeting.

Implementation using TCP
------------------------

Kim Kinnear started off with a bit of history about where the protocol
had been in the past, with the first definition using UDP, but that at
the meeting in Feb.  1999, there was a move to implement it using TCP.
He then described the general approach to the implementation (available
in the current failover draft, and also discussed in a separate document
already sent to this list on July 7, 1999, and available from Kim
([email-masked]))

The long and the short of the discussion was that the current approach,
using a single TCP connection for both failover functions (i.e., bulk
data transfer and to determine partner server connectivity) was
essentially ratified.  Several people expressed their belief that this
was a good approach, and there were no dissenting opinions heard.

There was some discussion that restarting a server using the TCP listen
port might take something like 2 minutes before it could successfully
open the TCP port again, and that the draft should indicate that if a
server couldn't open the listen port immediately it should keep trying.

Bernie Volz brought up a an issue with the times, and was concerned that
the time drift between two servers could cause a problem if the
connection was up for a very long time, since the time was only sent
during connection setup.  It was pointed out that the time is also sent
on contact messages, but that isn't a help because on a busy server a
contact message may well never be sent.

We realized that there are two problems here, small scale time drift,
and large scale time resets.  Both are issues.  In order to satisfy the
need to track both, we decided (after considerable discussion) to send
the time in every packet and to add a fixed 4 byte field with the time
to the packet header.  Then a receiving server can determine small scale
time drift from large scale time resets, and can do something reasonable
in each case.

Load Balancing
--------------

Kim introduced load balancing, and Steve Gonczi discussed the particular
algorithm.  Ultimately Rob Stevens said that load balancing could be
used between separate servers, not just between failover pairs.

After considerable discussion of the ramifications of multiple
non-failover servers doing load balancing, and multiple pairs of
failover servers doing load balancing between the pairs and among the
primary and secondary within a pair, we decided that it made sense to
remove the load balancing features from the failover draft and make it a
separate draft.  The failover draft will discuss how failover servers
use the failover protocol to configure the load balancing between
primary and secondary servers, but the details of the algorithm and its
use in non-failover contexts (including BOOTP relay implementations)
will be discussed in this separate draft.

Steve Gonczi offered to spearhead the new draft, with Ted Lemon and Rob
Stevens reviewing it and added content.  Kim asked to be kept in the
loop in order to properly update the failover draft.  Steve said that
he'd have something by the next IETF deadline (or earlier, since this
will be an first draft, so to speak).

Security
--------

Bernie discussed the TLS capabilities that he added to the draft in the
-04 version.  Ted suggested that he would like to have a way to do just
a simple digest using a simple shared secret, and Mark Stapp pointed out
that was already in the draft.

After discussions with Thomas Narten about the how to approach the
security issues, and Thomas' suggestion that we look at the SASL
approach to negotiate security issues, we agreed on the following plan:

1.  The draft would require implementation of a message digest which
will use some shared secret approach for the cipher (exact details TBD
by Bernie, looking at the DHCP authentication draft for guidelines).  No
user of the protocol would be required to use this approach, but every
server implementation would be required to have it.  This will (it is
hoped) pass muster since there is only a pair of server on which this
shared secret will have to be configured.

2.  Ted said that he'd investigate the SASL security negotiation drafts,
and see how we'd adapt them to the failover draft.  The approach would
be that we might well require SASL to negotiate the message digest and
cipher.  If we use SASL, we would certainly use it to negotiate the TLS
kind of encryption security which most agreed wasn't all that necessary,
but also agreed that there would certainly be people that would want it.

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

All in all, it was a very productive meeting -- and it
even ended early!  Thanks to all of the participants:

Burcak Beser      3Com                PDT   [email-masked]>
Ann Demirtjis     Microsoft           PDT   [email-masked]
Ralph Droms       Bucknell U.         EDT   [email-masked]
David Erdmann     Nortel Networks     EDT   [email-masked]
Steve Gonczi      Process Software    EDT   [email-masked]
Richard Jones     Checkpoint Software PDT   [email-masked]
Kim Kinnear       Cisco Systems       EDT   [email-masked]
Diana Lane        Wal-Mart Stores     CDT   [email-masked]
Ted Lemon         Internet Engines    EDT   [email-masked]
Thomas Narten     IBM/IETF area dir   EDT   [email-masked]
Greg Rabil        Lucent Technologies EDT   [email-masked]
Mark Stapp        Cisco Systems       EDT   [email-masked]
Rob Stevens       Join Systems        PDT   [email-masked]
Bernie Volz       Process Software    EDT   [email-masked]