Subject: [dhcwg] DHCPv6 Failover 2011-06-20 meeting notes, 2011-06-27 meeting invitation

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 20 Jun 2011 22:47:43 +0200

Here are the meeting notes from 2011-06-20 DHCPv6 Failover meeting.

The next failover meeting is planned for
2011-06-27 10:00 PDT (19:00 CEST)

Due to privacy concerns, the audio bridge number for the next meeting is
not going to be announced on mailing list. I will send bridge numbers
and/or current draft version to anyone who asks, though. Bridge details
and draft was sent to 18 interested folks before today's meeting.

We are planning to submit -00 of the DHCPv6 failover requirements draft
later this week. We will continue to have weekly failover meetings, but
they will shift focus to the next step - design document. If you would
like to comment on requirements document before it reaches IETF, you
should send your comments *now*.

Tomek

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

DHCPv6 Failover discussions minutes
June 20 2011, 10:00 PDT, (19:00 CEST)

Participants
- Alain Maes
- Benie Volz
- Jack Chen
- Kim Kinnear
- Shawn Routhier
- Tomasz Mrugalski

0.0 Agenda bashing
Kim - would like to add a discussion about the arrangement
of the current documnet.
	
1.0 Requirements document
1.1 Recent changes
  - Kim became co-author
  - draft is now informational (was standards track)
  - Network partition recovery is now a MUST
  - Many editorial changes (thanks to Kim and Bernie)

Discussion of document organization
Kim suggests putting the requirements list (section 4)
towards the end of the document.  There wasn't discussion
or dissent really so Kim will move the section as part
of his integration works.

Should we include descriptions of the other possible
ways of providing redundancy?  Some people think that
it's worth having at least a short description of the
alternatives for completeness while others feel that
this is a failover draft and doesn't really need this
and that shrinking the size of the document will make
it easier to get reviewed and passed.  There wasn't
a conclusion and the decision is left to the authors.

1.2 m-to-1
  - include in core or define as extension?

The experience of several people is that trying to support
m to 1 is not worth the extra effort - that the complications
outweigh the benefits.  We have some other folks that
feel that multiple relationships is either necessary or
useful.

The current position is that any given lease (or pool
if you prefer) will be served by a single failover
pair.  Any given failover server is allowed to
participate in multiple relationships if it desires, but
for each pool or prefix only a single relationship is
allowed. This latter option is more of an implementation
detail than a protocol question.  There is some
question as to the appropriate level - pool, prefix
etc - the basic idea is to find an appropirate grouping
that can be limited to a single failover pair.

1.3. Next steps
  - Kim will provide v4-failover-12 digest (1 or 2 pages)
  - initial -00 submission (this week?)

Should we push a draft to the mailing list soon?  It
may not be quite fully done yet but Bernie points out
that it would be useful to hold the discussions in a more
public venue so that there is an archive to allow either
new participants or ourselves to review the archive for
the history of the work.  We seem to have concluded to
publish as early as possible.

Kim has requested comments on the review of DHCPv4
that he has written up and circulated.  Tomek suggested
adding information about the state machine.  This leads
to a discussion about how much and which pieces of the
DHCPv4 failover document should be included in this
document.  Some of the items, such as the state machine
might be better off in the design document while others
might simply be included by adding a reference to the
old draft.  There is a little concern about if the
requirements document could be elevated to RFC status
if it has references to the old draft.

The requirements draft is being done as an informational
draft there is a question about how the design and
protocol documents would be handled.  Doing them as
informational might lower the bar in order to get
them passed as an RFC.  We are still unclear about
the need for inter-vendor interoperability - mostly
the conventional wisdom is that this isn't required but
we have at least one report that it there is a need for
this.  Deciding on the appropriate level is something
we can do when we start writing the next documents.

Suggestion to try and collect any areas of the DHCPv4
failover work that might need to be updated.  One question
for this is if such information would affect the
requirements document or would affect the design document.

One area mentioned is the possibility of taking advantage
of the larger IPv6 space in order to simplify the design.
One concern is that we might be constraining ourselves to
the way v4 did things.  While there is a general belief
that we should use what we can and what makes sense from
the DHCPv4 failover there seems to be a belief that we
should not be constrained to re-do v4.

General question on how to proceed should we continue
this series of meetings to work on the design document.

What should we say in the security section?  Feeling is
to go with whatever the standard boiler plate is for
requirements documents.

We have agreement that we should include a requirement
that the failover design must allow for securing the
communication between the two peers, though it is
not a requirement that they actually do use that
capability.  It is also desirable that the facility
is upgradeable in some fashion.

The rest of the agenda was deferred until next meeting.

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)

2.2 design topics suggested so far
 - lazy update
 - mclt
 - general state machine
 - TCP or UDP
 - Prefix delegation: fixed or variable lengths?
 - Conflict resolution mechanism: how to decide which data
   is "best"? Time? Sequence numbers?
 - transmission of information - design or protocol?
   Reuse bulk leasequery?
 - extension support mechanism

2.3 Next steps