Re: [dhcwg] DHCPv6 Failover -- LAST CHANCE

perl-list <perl-list@network1.net> Thu, 08 September 2016 13:25 UTC

Return-Path: <dankney@network1.net>
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 0A5A612B2C7 for <dhcwg@ietfa.amsl.com>; Thu, 8 Sep 2016 06:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Level:
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 lI9hZMR14ixu for <dhcwg@ietfa.amsl.com>; Thu, 8 Sep 2016 06:25:21 -0700 (PDT)
Received: from zimbra.network1.net (zimbra.network1.net [74.115.181.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0779412B5E0 for <dhcwg@ietf.org>; Thu, 8 Sep 2016 06:09:20 -0700 (PDT)
Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTPS id 43641540972; Thu, 8 Sep 2016 09:09:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 357605409C8; Thu, 8 Sep 2016 09:09:19 -0400 (EDT)
Received: from zimbra.network1.net ([127.0.0.1]) by localhost (zimbra.network1.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HdUHPdBtjI4t; Thu, 8 Sep 2016 09:09:19 -0400 (EDT)
Received: from zimbra.network1.net (localhost [127.0.0.1]) by zimbra.network1.net (Postfix) with ESMTP id 211B7540972; Thu, 8 Sep 2016 09:09:19 -0400 (EDT)
Date: Thu, 08 Sep 2016 09:09:19 -0400
From: perl-list <perl-list@network1.net>
To: tianxiang li <peter416733@gmail.com>
Message-ID: <313807947.869636.1473340159086.JavaMail.zimbra@network1.net>
In-Reply-To: <CAFx+hEPS+c1-d9TyOccLdhjDtBUots4LuXdDi6iV6ECaReb9eQ@mail.gmail.com>
References: <58B66897-2F0D-4916-AF5A-42D5DC172DE5@cisco.com> <CAFx+hEPS+c1-d9TyOccLdhjDtBUots4LuXdDi6iV6ECaReb9eQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_869635_865787994.1473340159085"
X-Originating-IP: [74.115.182.21]
X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - FF48 (Mac)/8.6.0_GA_1182)
Thread-Topic: DHCPv6 Failover -- LAST CHANCE
Thread-Index: Rz6Zly8zkH8h0jS7wogbF5wi8Ahw8Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/SoqKf7zskHMvplzhlbRgRUqBnh0>
Cc: dhcwg <dhcwg@ietf.org>, Kim Kinnear <kkinnear@cisco.com>
Subject: Re: [dhcwg] DHCPv6 Failover -- LAST CHANCE
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 08 Sep 2016 13:25:25 -0000

> From: "tianxiang li" <peter416733@gmail.com>
> To: "Kim Kinnear" <kkinnear@cisco.com>
> Cc: "dhcwg" <dhcwg@ietf.org>
> Sent: Wednesday, September 7, 2016 10:37:06 PM
> Subject: Re: [dhcwg] DHCPv6 Failover -- LAST CHANCE
> 4.2.1 Independent allocation

> “In this allocation scheme, used for allocating individual IPv6 addresses,
> available IPv6 addresses are permanently (until server configuration changes)
> split between servers…”

> If active-passive mode is used, it would mean that the addresses in the
> secondary server would not be used unless the primary server fails. In that
> case, wouldn’t permanently splitting the addresses between the primary and
> secondary server a waste of addresses?

> If the address pool in the primary server becomes scarce, wouldn’t a rebalancing
> mechanism be useful?

I read this section as just a codifying of what we do now without failover. We put half the /64 on the "primary" and half on the "secondary". It provides for some enhanced behavior where clients won't need to get a new address in the case of server failure as the remaining server can renew addresses. Also, you wouldn't need to do any math as the server would arithmetically split in half for you any subnets that are marked for this behavior. If offered a choice in the future, I would probably choose this method as it is the simplest. 

Also, this bit here: "It also assumes that the pool assigned to each server will never deplete." negates your comment about addresses becoming scarce. It is highly recommended (by all articles and documentation that I've seen) that all end networks be configured as /64 subnets. There are quite a lot of addresses in a /64. More than are in the entire IPv4 address space, is my understanding. It is unlikely that a /64 will experience IP address scarcity.