Re: [dhcwg] Load Balancing for DHCPv6

Donald Eastlake <d3e3e3@gmail.com> Fri, 07 September 2012 14:44 UTC

Return-Path: <d3e3e3@gmail.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 7834D21E80BA for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 07:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 kbqnaheRdgkh for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 07:44:56 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8327321E80B2 for <dhcwg@ietf.org>; Fri, 7 Sep 2012 07:44:56 -0700 (PDT)
Received: by iabz21 with SMTP id z21so3615836iab.31 for <dhcwg@ietf.org>; Fri, 07 Sep 2012 07:44:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ym/ISVZbyqOLKK0FQcjyFZO3sUBRJYnazUz+XVp+08c=; b=a/oJyIHoNmfw12e4yAXC7fzssnFR/oPyN0Ghv1E4ig+LRWApC40xfeAjDmI/npwINz b8nSY+5+GijwHxOW4jS44Sdxwb3g6eTnJxcEFQ/q9syvP+F8cU5knWR06b3oeDG44ps4 bOF5PI/nmahLuJokdF0l3EGJtXU2OyNURoD48jvUavEhJDtrx36yVEMy4yVcOwj8wLWE gaWhGEZKeghkw9KCeHNBS8E7UTFLC/GHMm07kByeyrgVupWxLt1zgocnyU7zQ6bec7VC vN5gr1bW7VZdtnuLmYGmGpxmm5ebPWnRBbhIBGUFDX7FSP7wUxVlQ+U0tnibzYnl96JW ZLyw==
Received: by 10.43.45.200 with SMTP id ul8mr7283696icb.36.1347029095986; Fri, 07 Sep 2012 07:44:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.143.103 with HTTP; Fri, 7 Sep 2012 07:44:35 -0700 (PDT)
In-Reply-To: <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com>
References: <CAL10_Bqa4ftiVhyyf0ezwKR7mzAEOLNi_K3EJFPFUzPnz7QGPw@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E0F4F3093@xmb-rcd-x04.cisco.com> <CAL10_Br=OcWZuar1fDOopevTy_W-3g9TsYqo61rOWm4tKkuYgg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E61118003F@GAALPA1MSGUSR9N.ITServices.sbc.com> <CAL10_BpXdx03WfV1PeMKg1zYc1dAFKe1CDNdrcNf45+_EVCBPg@mail.gmail.com> <CDDB9016-BE11-489A-9361-0172D96A464C@nominum.com> <CAOpJ=k2CJS=FuUvFwOq=s2m871_qfo=xROsW=fx0E48w2wxAqQ@mail.gmail.com> <CAL10_BoLsdppYKNSfHheYrZg+SfaggoynQf2X11HEdy=ELFUiQ@mail.gmail.com> <5049C317.7090603@gmail.com> <94FA926F-2432-4AE7-BC20-AE7458AB40D9@cisco.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 07 Sep 2012 10:44:35 -0400
Message-ID: <CAF4+nEHqRFHbz9qfQuOqpLCNeZqkT=+f53_eCboECfWX8QCt6A@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
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: Fri, 07 Sep 2012 14:44:57 -0000

If it is working fine, there is certainly no reason to change it,
which could lead to interoperability problems. But I'd be willing to
bet that FNV is superior...
https://datatracker.ietf.org/doc/draft-eastlake-fnv/

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Fri, Sep 7, 2012 at 7:16 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> Yes it can handle any length of data - the 16 limit came from max of chaddr. There is no harm in using whole duid, skipping type just reduces bytes used and as that field varies little it adds little.
>
> Sent from my iPad
>
> On Sep 7, 2012, at 5:49 AM, "Tomek Mrugalski" <tomasz.mrugalski@gmail.com> wrote:
>
>> On 06.09.2012 23:43, Andre Kostur wrote:
>>> bytes (only 2 beyond the 16).  The only one that is more of a question
>>> mark is DUID-EN as the vendor-specific identifier could be of
>>> arbitrary length.  The one case that we've heard of so far puts the
>> Sort of arbitrary, until you hit the limit of 128 octets, imposed by
>> 3315 section 9.1. I'm ok with lifting the 16 bytes limit (or rather
>> extending it to 128 bytes).
>>
>> There are some devices out there that are using DUIDs with duid type 14.
>> I have no idea what those devices are, I just saw traffic captures from
>> a production network. It is odd, but any server that follows 3315,
>> section 9 ("servers MUST treat DUIDs as opaque values") will handle them
>> ok. Anyway, my recommendation is to include the whole DUID as is in the
>> hash and don't to any clever things with duid types.
>>
>> Regarding hashing algorithm, I never heard anyone complaining about it
>> So don't fix it if it isn't broken. It can handle data chunks up to 128
>> bytes, right?
>>
>> Tomek
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg