Subject: [dhcwg] DHCPv6 failover meeting 2011-08-16

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 15 Aug 2011 23:31:15 +0200

Hi,
Due to vacation season, work on failover is progressing slower than
usual. Nevertheless, I'd like to continue this effort. Meeting schedule
will be in flux till end of August. Regular, weekly meetings will resume
by early September. Let me know if you have any preference regarding
schedule.

Agenda for tomorrow's meeting:

- Partner update
   - Time skew
   - Sending data
   - Conflict resolution
   - Acknowledging reception
- Endpoint states
   - State descriptions
   - Initializing FSM
   - State transitions
- Failure recovery
   - partner-down event
   - network-partition event
- Security

Meeting invitation and updated design draft will be sent soon to anyone
who expressed interest or participated in previous meetings.

Tomek

Please find necessary meeting information below:

Topic: DHCPv6 Failover
Date: Tuesday, August 16, 2011
Time: 10:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 804 574 300
Meeting Password: v6me

-------------------------------------------------------
To start or join the online meeting
-------------------------------------------------------
Go to
https://internetconsort.webex.com/internetconsort/j.php?ED=158985472&UID=491983767&PW=NNjA5ZDI0N2Q4&RT=MiM0
<https://internetconsort.webex.com/internetconsort/j.php?ED=158985472&UID=491983767&PW=NNjA5ZDI0N2Q4&RT=MiM0>

-------------------------------------------------------
Audio conference information
-------------------------------------------------------
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
Call-in toll-free number (US/Canada): 1-877-669-3239
Call-in toll number (US/Canada): +1-408-600-3600
Global call-in numbers:
https://internetconsort.webex.com/internetconsort/globalcallin.php?serviceType=MC&ED=158985472&tollFree=1
<https://internetconsort.webex.com/internetconsort/globalcallin.php?serviceType=MC&ED=158985472&tollFree=1>

Toll-free dialing restrictions:
http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:804 574 300

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://internetconsort.webex.com/internetconsort/mc
2. On the left navigation bar, click "Support".
To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://internetconsort.webex.com/internetconsort/j.php?ED=158985472&UID=491983767&ICS=MS&LD=1&RD=2&ST=1&SHA2=Z2iz206SYrt5erMHWaGksX8E-FaK6uRPqcWa0fVoitM=
<https://internetconsort.webex.com/internetconsort/j.php?ED=158985472&UID=491983767&ICS=MS&LD=1&RD=2&ST=1&SHA2=Z2iz206SYrt5erMHWaGksX8E-FaK6uRPqcWa0fVoitM=>

To check whether you have the appropriate players installed for UCF
(Universal Communications Format) rich media files, go to
https://internetconsort.webex.com/internetconsort/systemdiagnosis.php.

http://www.webex.com

CCM:+14086003600x804574300#

IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during
the session to be recorded. You should inform all meeting attendees
prior to recording if you intend to record the meeting. Please note that
any such recordings may be subject to discovery in the event of litigation.

---

From: Tomasz Mrugalski <[email-masked]>
Date: Wed, 17 Aug 2011 15:44:45 +0200

2011-08-16 DHCPv6 Failover Meeting minutes

Attendees:
Kim Kinnear
Shawn Routhier
Tomek Mrugalski

A brief summary of recent developments was given by Tomek. Tomek
apologized for sending updated version of the draft shortly before the
meeting, not earlier. There were no additional topics submitted, so we
started working our way thru the agenda. We continued our discussion
about design document from last meeting.

First topic discussed was the problem of clock differences between
partners. Shawn suggested that dependency on external mechanisms (like
NTP) that may be not available, especially during network partition
events is something that should be avoided. Kim proposed to reuse
mechanism from v4: each packet contains a timestamp as seen by
transmitting partner. Receiving partner stores its own timestamp during
packet reception and compares it with content received within the
packet. Calculated difference is then average along several recent
packets. This value is called time skew and is used during all time
related calculations.

Kim noted that while such algorithm is deployable, there still may be
occasional time differences. Therefore each time operation should not be
calculated precisely, but rather using fuzzy comparison. I values are
close enough to each other, they should be considered equal. Exact time
resolution is to be determined, but current perception is that anything
will less than 5 seconds difference should be treated as equal.

Related topic of time format was discussed. Tomek pointed out that
RFC3315 in Section 9.2 (definition of link-local+time-based DUID)
specifies timestamps as number of seconds since January 1st 2000 modulo
2^32, so we may reuse that. Time differences should be specified as
signed values to have the ability to express negative offset.

Another point was about general transmission format between partners.
Everyone agreed that we should try to reuse existing code if possible.
Since transmission is done over TCP, failover will reuse framing format
defined for bulk leasequery, just will define different message types.
Regular DHCPv6 option formats will be used.

The actual content of the lease update information to be exchanged
between partners was discussed next. We agreed that it is too early to
specify every bit of information as this belongs to protocol spec, not
design document. We named several mandatory elements. Kim suggested that
we should avoid specifying lease length the same way as was done in v4.
In v4 different values of lease lifetime was sent to client and to
partner. Kim referred to this as "lying to the partner". It was
suggested that partners should send 2 values: requested by client and
actual value assigned to client.

Discussion about absolute vs relative times was discussed next. Kim said
that it does not matter much. Tomek mentioned that absolute timestamps
may be more difficult to read. Shawn said that known implementation have
robust logging capabilities, so that is not a big problem. We agreed
that there are no strong opinions on that and either way will be fine.

The last topic discussed was conflict resolution. Different scenarios
were mentioned: server receiving unknown lease, server receiving old
state of lease while knowing better (newer) state etc. Kim suggested
that section describing conflict resolution will be basically a
flowchart that describes how to determine which lease is "better".

We will continue discussion during next meeting.

Tomek

2011-08-23 meeting details:

-------------------------------------------------------
Meeting information
-------------------------------------------------------
Topic: DHCPv6 Failover
Date: Tuesday, August 23, 2011
Time: 10:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 802 178 764
Meeting Password: v6me

-------------------------------------------------------
To start or join the online meeting
-------------------------------------------------------
Go to
https://internetconsort.webex.com/internetconsort/j.php?ED=158985497&UID=491983767&PW=NMTk3N2MzMTMz&RT=MiM0

https://internetconsort.webex.com/internetconsort/globalcallin.php?serviceType=MC&ED=158985497&tollFree=1

Access code:802 178 764

https://internetconsort.webex.com/internetconsort/j.php?ED=158985497&UID=491983767&ICS=MS&LD=1&RD=2&ST=1&SHA2=fDRkbEeFmwyysi7zbma2lTxpnZgVcfxQZO8V-oXAPus=

http://www.webex.com

CCM:+14086003600x802178764#