Re: [dhcwg] Load Balancing for DHCPv6

"Bernie Volz (volz)" <volz@cisco.com> Tue, 18 September 2012 17:44 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1E421F8522 for <dhcwg@ietfa.amsl.com>; Tue, 18 Sep 2012 10:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeQ9kavnDE-N for <dhcwg@ietfa.amsl.com>; Tue, 18 Sep 2012 10:44:06 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2168421F851C for <dhcwg@ietf.org>; Tue, 18 Sep 2012 10:44:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3064; q=dns/txt; s=iport; t=1347990245; x=1349199845; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qevywG1pd0Rmzos5+/0nI4lruB192QYWSvR3OVHPRUE=; b=gaqdDAzIH+NaTFKXGbS2TsXxvI3eBSCaELH7yXk1Vo7rst3tNVMzFc2r ATZaVpazEe+eprNQFzK3jKFFrIvCuvz1m6GssC93IpmnXpgSJ1/92w69G 1rrBJ9KtfQP+PmoeNW8WmZvCjgbtPn+RPkNiGvFs0cug39JgBeLQTzXcO s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAA2yWFCtJXG8/2dsb2JhbABFvEKBCIInEgFmEgEIDmolAgQOBSKHXpofoDiLGxQBhlsDlWOOOIFpgmaBWgE8
X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="122859294"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 18 Sep 2012 17:44:04 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8IHi4Pp006563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 17:44:04 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 18 Sep 2012 12:44:04 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Andre Kostur <akostur@incognito.com>
Thread-Topic: [dhcwg] Load Balancing for DHCPv6
Thread-Index: AQHNj2xDaJ+khP2NkUiXQs2wUqwOeJeHnBuAgAkHUwD//8KGAIAASEUA///OD4A=
Date: Tue, 18 Sep 2012 17:44:03 +0000
Message-ID: <CC7E2A2C.2585%volz@cisco.com>
In-Reply-To: <CAL10_BpPKCocKM1rzcxwv8LXQHxXUw9rOEfycRWyiRMLTsGsaw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [161.44.65.136]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004
x-tm-as-result: No--50.956700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <C47FC497E8FD304BBD833E9CF580811F@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] Load Balancing for DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Sep 2012 17:44:06 -0000

OK Š though having the client send lots of Renews seems less than optimal
to me (and the limited processing required by the load balancing servers
for these packets may be more than if the targeted server just answered
the first time).

I think this could always be an optional feature. Even if the servers had
different settings with respect to handling Renews, things would still
work correctly.

- Bernie

On 9/18/12 12:42 PM, "Andre Kostur" <akostur@incognito.com> wrote:

>On Tue, Sep 18, 2012 at 9:24 AM, Bernie Volz (volz) <volz@cisco.com>
>wrote:
>> First, I think this would be a rather bad change to DHCPv6 operation.
>> Client may be checking the server-identifier option they get back and so
>> you would have to lie about that in the response which just seems like a
>> very bad thing to do. (I don't believe RFC 3315 actually ever states the
>> clients should be checking the server-identifier, but I could be wrong
>>--
>> section 15 does say they check for the presence of the option, but do
>>not
>> check the contents). One could also think of situations where a relay
>> agent might forward the packet to explicit destinations based on the
>> server identifier (though again, I doubt anyone does this) -- much like
>> switches limit traffic based on mac-addresses.
>
>Note that I didn't suggest that server A preemptively answer the Renew
>coming in from the client (or impersonate server B).  Under my
>suggestion, the Renew would arrive at both servers A and B.  B would
>ignore it due to load balancing, and A would also ignore it due to the
>server ID.  The client continues to retry the Renews for the
>appropriate time, until it is time to Rebind.  At that point server B
>is still ignoring the client, but now A can answer the client as the
>Rebind isn't carrying a Server ID.  (And if we are talking about a
>Failover pair, then server A would already have a lease record for
>this client, and can extend that same lease.)
>
>For the relay piece, it would still need to forward the Rebind to both
>servers.
>
>[snip]
>
>> Anyway, I think this needs to be thought through much more carefully as
>>to
>> the potential consequences and I think the best is to keep it simple -
>> once a client has 'bound' to a server, it stays with that server until
>>it
>> issues a request message which does not contain a server-identifier
>>option.
>
>My scenario doesn't result in a client switching servers except under
>already defined RFC 3315 behaviour when the client has transitioned
>into Rebind.
>
>One piece that may have funny consequences is if the pair of DHCP
>servers aren't in some sort of cooperation mode, and this scenario
>would result in the client possibly changing IP addresses.  Client has
>to rebind, and server A does the DHCPv6 equivalent of a NAK and forces
>the client to come back to get a new IP.    Perhaps a server MAY skip
>the load balancing if the packet contains a Server ID (or even
>limiting it to the server's Server ID)?
>
>-- 
>Andre Kostur