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

"Bernie Volz (volz)" <volz@cisco.com> Tue, 22 April 2014 19:45 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9977D1A0265 for <dhcwg@ietfa.amsl.com>; Tue, 22 Apr 2014 12:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Level:
X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B7S2E5ejCwL for <dhcwg@ietfa.amsl.com>; Tue, 22 Apr 2014 12:45:54 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 828011A016E for <dhcwg@ietf.org>; Tue, 22 Apr 2014 12:45:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5962; q=dns/txt; s=iport; t=1398195917; x=1399405517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AQ3SEssHjUdO/lVoi2gX7Gi89I4bngrkWHdAAuYhcgA=; b=WUalzD7TwiZUQyI8aW74GxgM3K/PxM62+UUS5NqQ11lC3jkxN4EPdyJq iihr50AHbHceXHZ5fnc8FQBfoosKj+O8nyzJ00Sd/GObomkf6SjXDLAlF HVxeArMLq+2R3O1vjRaaHlCLXP0MgefQ3D3tKpV+gpbR1kGgKR7eHaGNf U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FANfFVlOtJV2d/2dsb2JhbABZgwaBJoMPwQ8ZfRZ0giUBAQEDAQ4VETENBwUHBAIBCA4DBAEBAwIGHQMCAgIwFAEICAEBBAENBQiIMQirBqIbF4EpjHwxBwaCaTWBFAEDq0KBcoE/gis
X-IronPort-AV: E=Sophos;i="4.97,905,1389744000"; d="scan'208";a="37833654"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 22 Apr 2014 19:45:10 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3MJjA2u000978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 19:45:10 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 14:45:09 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Andre Kostur <akostur@incognito.com>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014
Thread-Index: Ac8+ZAWxLB0+cGh7TmezKNoQaI9GngXcpL+AAisZhYAACFzlMA==
Date: Tue, 22 Apr 2014 19:45:09 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AFF33D7@xmb-rcd-x04.cisco.com>
References: <489D13FBFA9B3E41812EA89F188F018E1AF08ACE@xmb-rcd-x04.cisco.com> <5348284F.4060307@gmail.com> <CAL10_BpAJ_Ta0+nZT7OOPx-XqTbvT-ezqNU2=h7oRjyrA=kUVQ@mail.gmail.com>
In-Reply-To: <CAL10_BpAJ_Ta0+nZT7OOPx-XqTbvT-ezqNU2=h7oRjyrA=kUVQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.70.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/B4hmPXiNaz6HX5hDSCWItSOodjQ
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Apr 2014 19:45:59 -0000

Regarding Leasequery, I'd prefer to not do load balancing on these.

There's not much reason to load balance these because they generally are very 'cheap' for a server to process (no database writes, etc.). And, there isn't a clear path for how the request got to the server (i.e., went through relay or not), so it is more difficult to know if all servers got the request (though certainly if you mandate that some Leasequery requests can be load balanced, you'd also have to mandate that at least those requests are sent to all of the load balancing servers).

And there are also some failover interactions (at least there were with v4 because of lazy update and if load balancing is used in the failover relationship) that can result in the wrong answer.

- Bernie

-----Original Message-----
From: Andre Kostur [mailto:akostur@incognito.com] 
Sent: Tuesday, April 22, 2014 2:32 PM
To: Tomek Mrugalski
Cc: Bernie Volz (volz); dhcwg@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-load-balancing-01 - Respond by March 31, 2014

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