Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014

Andre Kostur <> Tue, 22 April 2014 18:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EF0561A0226 for <>; Tue, 22 Apr 2014 11:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pjVeneYI7oEV for <>; Tue, 22 Apr 2014 11:31:42 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id EE4301A0242 for <>; Tue, 22 Apr 2014 11:31:40 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Tue, 22 Apr 2014 11:31:36 PDT
Received: by with SMTP id ib6so3052608vcb.41 for <>; Tue, 22 Apr 2014 11:31:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U3BLWyIDHFKegyMrG8ENMS9vS2pTjYsVFK+pggXFgAU=; b=BGyTp04/8VmdcwmPB6pMxaBdVWLHMCu+yWuI3q8/tM6KE4sN4ZtjZtozJP2qEHO8lQ MHIi6sFtkZ9C3CK4gbiajKIUkx0ylgVxVf9VX3k9FHuOQMmn2D+iWq5HmfBUj8IBO7WD nTr3NuQ/4dTsF3AzaGOIUTlncbL3eUmOH9OGgzvoWA8Xzs0chbDdYnN9rji/qABQm9D1 Wi6SP9WxmwZHvQvV3eKsa9rI7s6xFEa1Ndq+Gn9zz6v/o4CySLKGYhI/x2P9eK7RQ64p kPQZ2K/gxkNDgY5vQsz58D9B/TUgR3d+sliDgYDXi8greJphg+HCzTby0Qln4huj23pp METw==
X-Gm-Message-State: ALoCoQlxtClBJzWZZ3OUW0w06FdBqSetE8dFu9kVuAVOYUwnsT+Ke0D1vOa1sJB69lwxQF0JyE2HCENHnxE5OzUh5aFMY5Y7dwnvK1NxsE5WOPp4gPpuXtmap/ArVHdFyaozqOhQnx0A
X-Received: by with SMTP id ij3mr8501114veb.26.1398191494870; Tue, 22 Apr 2014 11:31:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id ij3mr8500989veb.26.1398191493307; Tue, 22 Apr 2014 11:31:33 -0700 (PDT)
Received: by with HTTP; Tue, 22 Apr 2014 11:31:33 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 22 Apr 2014 11:31:33 -0700
Message-ID: <>
From: Andre Kostur <>
To: Tomek Mrugalski <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>, "Bernie Volz \(volz\)" <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Apr 2014 18:31:44 -0000

Some of the changes have been integrated, but a few discussion points remain:

> Also "LEASEQUERY and its extensions...". That's
> sort of obvious that bulk and active leasequery are out of scope for
> load balancing as they are TCP based, but it's better to be explicit here.

I'm a little unclear as to what change is suggested here.  Change
"LEASEQUERY" to "LEASEQUERY and its extensions" ?

> 4. "LEASEQUERY messages with a query based on Client ID SHOULD have load
> balancing applied to them". This one is interesting. I would assume that
> leasequery messages are sent to specific server directly, so they are
> outside of scope for load balancing. Furthermore, I think it is legal to
> send QUERY_BY_CLIENTID queries over TCP connection. Obviously, load
> balacing is out of scope for any TCP connections.
> I don't have any strong opinion here, but I think leasequery should be
> not load balanced at all, regardless of the query type. I talked about
> this with Bernie and he seems to agree with that. If you still want to
> keep that text, I think it should say "LEASEQUERY message with a
> QUERY_BY_CLIENTID that are sent over UDP SHOULD have load balancing
> applied to them."

The document does already specify that it only applies to UDP DHCPv6
messages.  Devices doing leasequery are likely configured to send to
all DHCPv6 servers that they know about, and part of the goal is to
help reduce the load on the servers.  Thinking a little more on this,
I agree that in the general case of load balancing, the server's don't
necessarily know which server has allocated the IP, so this probably
should but a MUST NOT.  However, in the case where the servers are
sharing lease data, this could be relaxed to a MAY so that it can
still take advantage of the lessening of the load.  This would come
into play when the servers may be under a heavy load already due to
their populating having rebooted and the routing element (CMTS?) is
rebuilding its IP association tables.

> 6. Still in section 3: "DHCPV4-QUERY [I-D.ietf-dhc-dhcpv4-over-dhcpv6]
> messages SHOULD NOT be load balanced, but should be subject to DHCPv4
> load balncing, if the server supports it.". Did you want the second
> "should" to be capitalized?
> That one is interesting. Right now the DHCPv6 relay does not need to do
> any special about DHCPv4-over-DHCPv6 messages, just forward them towards
> the server (it may do fancy things, but it doesn't have to). With this
> statement, suddenly it becomes much more complex, as the DHCPv6 relay
> should become DHCPv4 aware, DHCPv4 LB aware and have separate
> configuration for DHCPv4 LB. Nowadays, realistically speaking relays
> which do LB for DHCPv6 will also do LB for DHCPv4. But this may not be
> the case in a decade or so.

According to that draft, the relays don't participate in the v4
decisions.  If they receive a DHCPV4-QUERY, they may send those
messages to a different server than their general DHCPv6 servers.
Where this comes into play is on the DHCP 4o6 Server.  I'd like those
servers to not decide on load balancing based on the DHCPv6
properties, but to make that decision based on the DHCPv4 properties
if the 4o6 server has implemented DHCPv4 load balancing.

Andre Kostur