Subject: [dhcwg] DHCPv6 failover 2011-07-14 meeting, 2011-06-27 notes

From: Tomasz Mrugalski <[email-masked]>
Date: Thu, 14 Jul 2011 00:36:11 +0200

Due to vacation and other conflicts, v6 failover meetings are not held
on Mondays anymore. We will probably get back to Monday schedule after
Quebec, though. The next one is planned for

Thursday, 2011-07-14 10:00 PDT

Please contact me if you want to participate. Anyone who ever expressed
interest or participated in previous failover meetings will get an
invitation with bridge details.

Apologies for sending minutes from the last meeting with such delay.

DHCPv6 Failover meeting notes
June 27 2011

Participants:
Bernie Volz
Grag Rabil
Kim Kinnear
Shawn Routhier (notes)
Tomek Mrugalski

Agenda:
No additional agenda items.

1. Requirements document status
 - initial -00 published

Inital requirements draft published, thanks
from Tomek to everybody that contributed to
the document.

Further discussion of the requirements document
should be held on the dhcp mailing list.

Kim suggests that sections 4 and 5 are a little
unclear and may need some reworking.  Some of the
items aren't necessarily failover and some of the
items that have been separated may be included
together.  Mostly this doesn't seem to be any issues
with the concepts but simply with how they are laid
out and described.

More text to be circulated.

2. Design document

2.1 Initial discussion on design document:
 - Goals (design vs protocol)
 - Timelines (probably not for Quebec, we may meet during
   IETF, though)

Current plan is to have two additional documents besides the
one that was just published (requirements): one for design and
one for protocol with the possibility the protocol doesn't
get done depending on the IETF.

Current goal is to have a first draft of the design document
for Taiwan (Novemeber 2011).

The consensus seems to be to request the WG to adopt the
requirments draft in the Quebec time frame and hopefully
to request adoption of the design document later.  Some
question about the appropriate document label - standards
track, informational etc.  The requirements and design
are likely not to be standards track but informational
or BCP.

Discussion about work effort involved in design and protocol
documents.  While we may not create an inter-vendor protocol
the design should assume that is our goal and make design
trade-offs accordingly.

2.2 design topics suggested so far
 - lazy update

We assume this is required for performance reasons.
When to do the update remains to be deteremeind. It
is likely there will be suggestions that updates
occur based on both activity and time.  For example
a server SHOULD update after <foo> acitviity and
MUST update after <bar> time.

 - mclt

This was a solution to the interaction of lazy update
and a partner disappearing in DHCPv4.  MCLT is the
suggested solution but other solutions will be
evaluated as they are presented.

An interesting question was asked by Tomek - do we want
to handle Prefix Delegation and addresses in the
same fashion or should we allow the mechanisms to
be different for the two?  This brought up a discussion
about how addresses are split between the two servers.
As there are different ways for servers to use and
address pool and therefore split that address pool
between the design document will likely need to address
the different options.

The MCLT question is somewhat separate from the pool
distribution question.  Once a server has allocated
an address it will need to inform the peer of that
and have methods of working in the presence of lazy
update.

 - general state machine

Defered till later.

 - TCP or UDP

TCP.  This battle has been fought before and absent
new information going with TCP seems to be the best
option.

 - Prefix delegation: fixed or variable lengths?

Variable lengths is the current plan.

 - Conflict resolution mechanism: how to decide which data
   is "best"? Time? Sequence numbers?

Deferred till later.

 - transmission of information - design or protocol?
   Reuse bulk leasequery?

Discussions of bits on the wire is probably a protocol
issue.

 - extension support mechanism

This is something we want but writing a design document
that doesn't morph into a protocol document may be hard.
The general ideas seem to be some sort of handshake
between the two servers to indicate what extensions they
support.

2.3 Next steps
 - vacation

Tomek on vacation for a while, next meeting scheduled
for July 14.

 - failover meeting in Quebec

Some discussion of when to meet in Quebec.  Several
folks won't be in Quebec so trying to have a conference
call would be useful.