Subject: [dhcwg] DHCPv6 Failover 2011-06-06 meeting minutes

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 06 Jun 2011 23:39:04 +0200

Here are the minutes from initial DHCPv6 Failover requirements meeting.

Invitations to that meeting were sent to anyone who responded to my
request for participation, previously announced on DHC mailing list:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg11652.html

Ted Lemon pointed out that this is not acceptable approach, so I'd like
to announce that this was only the first one in a series of weekly
meetings. The next meeting is tentatively scheduled for:

Monday, 2011-06-13 10:00 PDT

Bridge info will be sent out shortly to all who expressed interest in
this work and to the list as well.

Please contact me if you want to receive current copy of the draft, have
comments, suggestions, agenda items for next meeting or would like to
state your preferred schedule.

Note: This is preparatory work for initial draft. You are welcome to
join in if you want to participate in this work from the very beginning,
even before initial submission.

Regards,
Tomek

 DHCPv6 Failover requirements meeting - 2011-06-06
---------------------------------------------------

Participants:
1. Jack Chen (Time Warner Cable)
2. Kim Kinnear (Cisco)
3. Alain Maes (Alcatel Lucent)
4. Tomek Mrugalski (ISC)
5. Shawn Routher (ISC)

0. Announcement
  Ted Lemon asked to be sure that all meetings are announced on the DHC
  WG mailing list, and that minutes (if any) are also distributed there.

1. Agenda bashing
  No changes to the agenda sent in the email

2. Work flow (how to organize work)
  a) sending comments, editor updates
  b) token based

  Discussion of how to do the editing - one editor accepting changes vs
  token approach of multiple people doing the editing and passing a
  token around as to who is doing the editing.  Shawn said that he
  thought that documents were more consistent if one person edited them.

  Kim said that he thought that the requirements document was short
  enough that having a single editor was probably ok, but that in a
  longer document we might want to pass the token as necessary.
  Sometimes it is a lot easier to edit the changes and let people see
  them as diffs as opposed to sending in change after change.

  Currently planning on one editor managing the work (Tomek).

3. Meeting schedule and deadline
  Due date for this document is July 4.  Weekly calls?
  Consensus: Yes.

  Kim and Tomek offered webex, nobody seemed to need it.

  Tomek suggested people send preferences on times to him. No
  preferences received so far.

  Planning on weekly calls, currently planning on using the ISC bridge
  but may switch to webex if that is more convenient for people.

4. Next steps after requirements document?

  a. Design Document

  b. Protocol Document

  Considerable discussion ensued.  Overall, seemed like the
  discussion came around to: focus first on design, then on
  protocol if there is still energy and need for it.

  Shawn said that if the design was 10 pages, then having it on the
  front of the protocols document would make less to get through
  IETF.

  Kim said that the v4 failover document was just so long that it
  couldn't make it though, and having the design approved would
  make it a lot easier to get the protocol pushed through.

  Kim also brought up the issue of whether there is a consensus
  about needing an intervendor protocol document (which is protocol
  documents at IETF are typically about).  One of the problems with
  getting the v4 protocol document through was that there wasn't a
  huge amount of desire for an intervendor protocol -- i.e., a
  protocol that would work with the main server from one vendor and
  the back from a different vendor.

  The other folks on the call agreed that we haven't to date, seen
  much customer pressure for this in the DHCPv4 space.

  There seems to be strong pressure to have a failover option but there
  does not seem to be pressure to have an interoperable specification
  between different vendors.  (Corrections from the user community would
  be quite useful at this time.)

  That doesn't mean that we can't do a DHPCv6 protocol spec, but it
  does mean that this is an issue we need to work through.

  Current feeling seems to be to plan for 3 docuemnts requirements,
  design and protocol.  If it makes sense to collapse the last two
  (design and protocol) into a single document that would be something
  to consider but that should be deteremined when we get part/most of
  the way through the design.

5. Discussion of comments received so far

  a. Make it clear that m-m is not applicable, and 1-1 is the
  goal. Each IP address or prefix is handled by at most two servers in
  a failover pair.  We had a discussion about whether any server
  should be allowed to be in more than one failover pair.  The v4
  version allows for one server to be in multiple pairwise failover
  relationships.  This allows for a central or back office approach.
  This seems like a good idea in theory but has some drawbacks in
  practice.  Getting more feedback from actual large users about such
  use would be good.

  b. There was a question about "lease stability", and whether that
  was a goal.  That is *already* a goal in the document, and consensus
  was that it should certainly stay as a goal. Agreement that the v6
  version should include support for prefix delegation.

  c. How many servers "know" about one IP address?  Two was the
  answer.

  d. VRRP:  Frank Sweeter said that the DHCPv6 multicast covered
  this case.  Kim suggested that we believe that until and unless
  someone comes up with more specifics than "you should look at
  this RFC".

  e. We should put something in the document about whether or not
  we are planning to handle network partition events.

  Kim said that a large (maybe 30%) of the DHCPv4 failover
  document is involved in handling network partition events.
  Thus, we don't want to take on that work lightly.

  Kim said that while these events are rare, they do come up.
  There was some linkage of network partition events with
  geographical distribution of failover servers, since it is
  obviously easier to have such events if the failover servers
  are not in the same place.  Shawn said that until recently, he
  would not have thought that anyone really cared about network
  partition events, but after talking to some customers recently,
  he now believes that it is important to handle this situation.

  Shawn said that it would be nice if people could enable or
  disable the code to handle network partition events, but if
  that wasn't possible or made things too difficult, then he
  would understand that it has to be built into every implementation.

  Discussion of network partition vs partner down.  We think there are
  probably two basic groups - large enterprises and ISPs that probably
  want geographic separation and either are willing to pay for it or
  already have the facilities set up - smaller enterprises that may
  have a single campus (even a large campus) and are content to have
  multiple servers but not widely separated, for example 2 servers in
  the same machine room.  There seems to be agreement that we do need
  to support network partition.  We may be able to do this as an option.

  Discussion of lock step vs lazy update.  There is general agreement
  that lock step isn't viable. Performance penalty was one of the
  reasons.

  f. Discussed new items for the section 4 requirements;

    i.  Network partition - add

    ii.  Lazy update - add

    iii. Load balancing must at least be considered, but at least Kim
    and Tomek felt that load balancing should actually be documented
    in a separate document. Nobody else expressed much of opinion on
    this.

  g. General consensus on the fact that the DHCPv6 failover will
  replicate the information in the lease state database.

6. Discussion on authors
  Otherwise known as "whose name is on the draft".  Tomek said that
  12 people responded as wanting to help, and that was to many to have
  as authors.

  Shawn said that he felt that Tomek should be the "editor", everyone
  else should be a contributor mentioned in toward the end of the
  document.

  Kim said that, at the time the draft was submitted, that it was
  unlikely that 12 people would have participated, and that it
  would make sense to put the people who really contributed as
  authors of the draft.

7. extra topics
  What about the promise of v6 - that we can simple move from a valid
  to a new preferred address?  Given that we are using DHCP instead of
  autoconf this doesn't seem to have gotten far enough yet.  The reality
  seems to be that end users want and providers want to provide address
  stickiness - that the end user continues to get the same address when
  possible.  Prefix delegation is also an issue in this.

8. Invited participants:
- Kris Bransom (Comcast)
- John Brzozowski (Comcast)
- Jack Chen (Time Warner Cable)
- Gaurav Halwasia (Cisco)
- David Hankins (Google)
- Kim Kinnear (Cisco)
- Suresh Krishnan (Ericsson)
- Ted Lemon (Nominum)
- Alain Maes (Alcatel Lucent)
- Tomasz Mrugalski (ISC)
- Jiang Sheng (Huawei)
- Frank Sweetser (Worcester Polytechnic Institute)
- Shawn Routher (ISC)
- Jean-Francois Tremblay (Videotron)
- Bernie Volz (Cisco)
- Qin Wu (Huawei)

Thanks to Shawn and Kim for providing excellent minutes.

---

From: Tomasz Mrugalski <[email-masked]>
Date: Wed, 8 Jun 2011 13:22:54 +0200

On 11-06-07 17:50, [email-masked] wrote:
> Sorry I missed this discussion.  I would have liked to attend, but I
> was travelling yesterday.
Next meeting is scheduled for June 13, Monday 10:00 PST (19:00 CEST). I
will send out bridge info and agenda shortly before the meeting.

> As one of the original authors of the DHCPv4 Failover draft, I would
> like to participate in these discussions going forward.  I would echo
Great! Welcome aboard.

> many of Kim's comments about that v4 draft.  What started as a simple
> solution became an extremely bloated spec that stood no chance of
> making it through the IETF.
Yes, I agree completely. That's why we are trying to do this in smaller
pieces. Current plan is to have:
1. requiremenst document
2. design document
3. protocol spec document

We will try to push any non-mandatory features to separate extension
documents. By non-mandatory I mean features that are not required in
some scenarios.

> I believe that any documents that we create should provide some
> clarification about when it is appropriate to use failover, and when
> it may not be.  For example, if there is no real strict need for the
> client to maintain the same IP address, then the 'preference' option
> could be used to provide some level of redundancy.  Also, in cases
> where DHCP is used briefly for a bootstrapping clients (i.e. PXE),
> failover may not be appropriate for this setup.
Good points. I'll add small section that explains this.

Tomek

---

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 13 Jun 2011 22:28:32 +0200

Here are the minutes from second DHCPv6 failover requirements meeting.

Bridge info was sent to anyone who responded to my request for
participation or otherwise expressed interest. The next meeting is
scheduled for:

Monday, 2011-06-20 10:00 PDT (19:00 CEST)

I would like to point out that this is pre-IETF activity. Failover
requirements draft will be published in less than 2 weeks and will
follow the usual IETF way.

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.

It seems that there is general agreement regarding the shape of
requirements document. Discussion is trending towards initial design
aspects - something that will eventually become v6 failover design document.

Tomek

-------

Failover requirements - June 13 2011
10:00 am PDT (19:00 CEST)

Attendees
- Greg Gabil (Jager Net Technologies)
- Kim Kinnear (Cisco)
- Suresh Krishnan (Ericsson)
- Tomasz Mrugalski (ISC)
- Shawn Routher (ISC)

1. Agenda bashing
No additional agenda items

2. Summary of latest changes to requirements specification

- Added clarification that "2 peers" means a pair (2 servers in total,
  not 2 backup servers + primary)
- Added requirement that failover must not impact performance too much
  (i.e. lazy updates should be used)
- added description of failure modes (server-down and network partition)
- added description of possible synchronization modes (lockstep
  vs lazy updates)
- Added requirement that protocol must be able to recover from
  server-down event
- Added requirement that protocol should be able to recover from
  network-partition event

- Added section about failure modes (server down vs network partition)

- Added section about failover alternatives. It documents scenarios,
  where failover is not really needed

- Removed referenced to VRRP as suggested by Frank Sweetser and Kim Kinnear

- Removed random questions section

- Added a clarification that 1-to-1 is the only scenario that is
  covered by the failover scenario. Also added a note that m-to-1 may
  be achieved as multiple instances of 1-to-1, but such cases are
  considered deployment scenarios and are irrelevant from the protocol
  point of view.

- Cleared up a misconception that failover can be used as load
  balancing "for free". As each partner must be able to handle the full
  traffic in case of partner-down event, there's no real benefit in
  using failover for LB purposes.

3. Topics proposed by Kim

- Lease database sync - TCP or UDP?
  Probably TCP - no discussion

- Transmission of information. Should it go to design or protocol
  document? Should it be based on bulk leasequery? BLQ with changes?
  Something else?
    This is being deferred to the design discussion.

Discussion of what should be in the requirements document.  In
particular should we include non-goals such as n-1 in the text.
We all seem to be agreeing that we want a simple solution we
seem to be having some question as to what to say and how to
say it in the document.

Should we allow or prohibit n-1 relationship.  There is a
push to limit ourselves to 1-1 with each peer in only one
relationship.  This is based on some experience with the
complications that arise from trying to allow one peer to
be in multiple relationships.  A suggestion is to leave this
as a potential extension, the base document would only support
1-1 with one relationship while an extension could be written
to allow for multiple relationships.

- conflict resolution algorithm - how to decide which data is
  "best"? Time? Sequence numbers?
    This is being deferred to the design discussion.

- MCLT - maximum client lead time (a concept used in v4 failover)
    This is being deferred to the design discussion.

- Lazy update - frequency
   Some discussion about frequency and latency.  We seem to be
   in general agreement that we need something like lazy update
   in order to minimize impact on the performance of the server.
   We won't have a requirement to batch any specific number of
   requests though batching is a likely implementation strategy.

4. Next steps
- What should we do for our next steps.  Should we start working
  on the design document or should we wait for feedback from the
  working group either on the email list or at the Quebec City.
  There's some thought to wait until we get feedback but mostly
  it sounds like we can and should start working on the design
  as we have time and energy.

- Previously we had heard that cross-vendor interoperability was
  not really necessary.  We have one person that feels that this
  is a requirement.  Determining if this is a true end-user
  requirement will be good.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Mon, 13 Jun 2011 16:34:20 -0400

Hi Tomek,
Please update your minutes for my contact info as an attendee:

Greg Rabil - Jagornet Technologies

Many thanks,
Greg

On Mon, Jun 13, 2011 at 4:28 PM, Tomasz Mrugalski <
[email-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>