Subject: Minutes from Dec 7 Failover conference call

From: Kim Kinnear <[email-masked]>
Date: Tue, 7 Dec 1999 17:39:01 -0500 (EST)

Minutes from Failover conference call, held
December 7, 1999 12-2pm EST.

Kim Kinnear, [email-masked]

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

NOTE:  There will NOT be a conference
call this Thursday, December 9!

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

The agenda turned out to be:

1. Security and export controls
2. SASL investigation 
3. Timestamp format - should it be NTP
4. What changed for the -05 draft
5. Document organization
6. POOLREQ -- is this a good technique
7. PARTNER-DOWN and MCLT wait
8. Where do we go from here, short and long term
9. Bulking and group acking

Thanks to everyone who attended:

David Erdmann     Nortel Networks     EST   [email-masked]
Steve Gonczi      Process Software    EST   [email-masked]
Richard Jones     Checkpoint Software PST   [email-masked]
Kim Kinnear       Cisco Systems       EST   [email-masked]
Ted Lemon         Internet Engines    EST   [email-masked]
Chris Petrick     Nortel Networks     CST   [email-masked]
Greg Rabil        Lucent Technologies EST   [email-masked]
Bernie Volz       Process Software    EST   [email-masked]

Notes on each topic are below:

1. Security and export controls
------------------------------- 

David Erdmann brought up the concern that with TLS we might get
into export control problems.  Bernie Volz said that we'd picked that
particular cipher because SMTP and IMAP were using it, so
presumably it was "ok", but that he'd certainly check on it.

2. SASL investigation 
--------------------- 

David also wondered where the SASL investigation was, and Ted
Lemon said that he hadn't had time to look into it yet, but he
was going to in a week or so.  Richard Johnson said that he was
interested in this as well.  

3. Timestamp format - should it be NTP
-------------------------------------- 

Kim Kinnear reported that someone had suggested using the NTP
64-bit time format for times for failover.  He did a bit of
research, and discovered that the NTP 64-bit time is 64-bits of
fixed point number.  It is 32 bits to the left of the fixed
point, and 32 bits to the right.  It is based on seconds since
1900 (not 1970), and even though it is unsigned, it expires in
2036.

Kim proposed *not* using the NTP time format, but rather using a
32 bit *unsigned* time format, similar to the ANSI time_t format
for the low order 31 bits, but unsigned.  This will not expire
until 2106 or so.  The rest of the folks agreed.

Richard had pointed out in his review that network byte order
wasn't specified for the time options, and Kim said that in the
next revision he would have a section on time, and reference all
times to that section to explain their format.

4. What changed for the -05 draft
---------------------------------

Kim gave a quick list of what changed in the -05 draft
from the -04 draft.  This list includes:

o new DDNS text from Mark Stapp
o removed load balancing per contributions by Steve Gonczi
o updated security section with new text from Bernie Volz
o added new DHCP client "option buckets" 6.2.27-28
o added new RESOLUTION-INTERRUPTED state
o new section on binding-status state transitions 5.10
o new section on conflict resolution 5.10.1
o new section on reservations 5.12
o new section on dynamic BOOTP 5.13
o put the time in every packet, not in option
o more info on DHCP protocol requirements
o clarified NAK behavior
o clarified how to select MCLT 5.14
o added STARTUP state to section 5, 5.8
o clarified which BNDUPD part of UPDDONE
o changed MAC address to client hardware address
o changed "packet" to "message"
o removed RELEASED-GRACE and EXPIRED-GRACE binding-statuses

5. Document organization
------------------------ 

Richard proposed partitioning the draft into a strict protocol
section and then an explanations and elucidations section.  This
met with some approval, until Kim voiced a concern that yet
another reorganization without tightening up what we've already
got would *look* like progress without perhaps *being* progress.

Kim committed to another edit in an attempt to tighten up what we
already have, with the goal to lean it down and, while increasing
clarity, remove about 20 pages.

We all agreed that we'd look at it after this tightening up, and
if we needed to reorganize it, we'd do it then.

Kim's tasks for the next revision are:

o relate the NAK errors to the rest of the draft
o fix up the times (from #3 above)
o integrate any security changes from Bernie, Ted, Richard
o reorganize conflict resolution into tabular form
o ensure that you can't do both TLS and simple message digest 
o bulking
o add text for PARTNER-DOWN (see #7 below)
o include test in 7.1.1 about mapping both directions
o include Richards comments
o include any other comments he receives
o give entire draft editorial review

Please review the -05 draft and send Kim corrections
and suggestions: [email-masked]

6. POOLREQ -- is this a good technique
-------------------------------------- 

Steve Gonczi voiced a concern about the POOLREQ message, in light
of the new loadbalancing approach first adopted in the -04 draft.
Having the primary server send addresses to the secondary server
is nice if the secondary server isn't doing much, but if it is a
major player with DHCP clients, then sometimes the primary server
might need some of the secondary server's IP addresses.

Bernie indicated that the primary server can always ask for them
back from the secondary server if it needs them using BNDUPD
messages.

We discussed for a while allowing the primary server to send
POOLREQ messages to the secondary server, or dropping the POOLREQ
messages altogether and letting each server attempt to pull its
addresses from its partner.  Kim brought up a red-herring about
differing configurations, which in retrospect isn't really an
issue, since so many configuration issues must be the same that
one more doesn't mean much of anything.

At the end of the discussion we didn't agree to changes, but I
believe that Steve said that he might bring it up on this list
for further discussion.

We did agree to add words to suggest that when an address
goes FREE from a secondary server, that the primary server
should probably send it right back to the secondary server.
Of course, not every server will track this because once
an IP address is leased, there is no reason to remember which
server once had it available.

7. PARTNER-DOWN and MCLT wait
-----------------------------

Bernie brought up the issue that, when entering PARTNER-DOWN
state via command, you need to wait the MCLT from when the
partner server went down before using that server's free IP
addresses (and in the absence of any better information, that
time is probably when you got the command).  However, if you go
into PARTNER-DOWN because of a timer that went off in
COMMUNICATIONS-INTERRUPTED state, then you might presume that the
MCLT has already expired for those free addresses.

Kim pointed out that there was another MCLT wait in PARTNER-DOWN,
that from when a lease expires.  That MCLT wait *must* exist in
any case.

Bernie proposed a new state, but we ultimately agreed that we'd
just document that one could assume the MCLT had run out in the
automatic transition to PARTNER-DOWN.

8. Where do we go from here, short and long term
------------------------------------------------

The current plan is:

o produce -06 draft during January
o another conference call late Jan/early Feb
o produce -07 draft prior to Adelaide
o produce -08 draft post Adelaide, last call candidate
o produce -09 draft with changes required for last call

Obviously the last two items are somewhat speculative,
but they are a goal.

9. Bulking and group acking
--------------------------- 

Steve also brought up the issue of bulking, and the way in which
we might ACK.  Kim mentioned that we need to get bulking in the
next revision if we are going to do it at all.  Steve said since
we are using TCP, what about acking only the "latest" BNDUPD, and
let that be an ACK for all previous BNDUPD's.

Kim said that the big performance win with bulking was because
the database flush could be held until the end of all of the
database updates in a bulked packet.  He suggested that the same
could be done with ACK's, but it is harder.

Ted pointed out that to do the "ACK only the last" approach
requires an ordered list of ACK's be kept, and Kim said that some
implementations might not want to keep such a list.  Then Kim
pointed out that a new implementation might not even keep
outstanding BNDUPD messages around at all, but might well just
rely on the partner to send back the BNDACK messages, and update
the lease database based solely on the BNDACK messages.  This is
possible since retransmission is not required.

We ended up leaving it the way it was, with Steve probably going
to bring it up on the list for further discussion.

----------------- end of minutes ---------------------