Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

Erik Nordmark <nordmark@sonic.net> Wed, 26 February 2014 19:33 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD581A084B for <ipv6@ietfa.amsl.com>; Wed, 26 Feb 2014 11:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 RPMcqYeZbcwA for <ipv6@ietfa.amsl.com>; Wed, 26 Feb 2014 11:33:11 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 101821A01E4 for <ipv6@ietf.org>; Wed, 26 Feb 2014 11:33:11 -0800 (PST)
Received: from [192.168.10.18] ([78.204.24.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s1QJVxQf027115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Feb 2014 11:32:00 -0800
Message-ID: <530E412E.7000500@sonic.net>
Date: Wed, 26 Feb 2014 11:31:58 -0800
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ole Troan <otroan@employees.org>, Erik Nordmark <nordmark@acm.org>
Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
References: <5305AF13.5060201@acm.org> <7461F3DA-FB05-400D-9C54-2F30C73DE2B9@employees.org> <530BCF83.4090500@acm.org> <F401125A-6D2F-4306-85E2-F13DDDCAA7F3@employees.org> <530CAC9D.1040105@acm.org> <2CFB5723-A676-4ADD-B555-83752997CFD7@employees.org> <530D10C2.3080208@acm.org> <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
In-Reply-To: <847BE1A6-1A6F-4265-BF4A-67AD87504EDC@employees.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;tEQDqRyf4xGciyGQCY+HFQ== M;vsmlqRyf4xGciyGQCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mJVYrj6DbI5jHCL3Vb3zmmZfzTk
X-Mailman-Approved-At: Wed, 26 Feb 2014 12:14:42 -0800
Cc: Andrew Yourtchenko <ayourtch@cisco.com>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 19:33:17 -0000

On 2/26/14 3:31 AM, Ole Troan wrote:
>
> there is work apparently on failover:
> RFC7031
> draft-ietf-dhc-dhcpv6-failover-design

Looking at those docs, they design seems to focus on address assignment 
using a pair of servers. For instance,

    A subset of available resources (addresses or prefixes) is reserved
    for secondary server use.  This is required for handling a case where
    both servers are able to communicate with clients, but unable to
    communicate with each other.

That is insufficient for address registration, since AR assumes it 
should work unless somebody else has registered the address. Thus this 
would typically require a quorum (2 out of 3, 3 out of 5, etc) so ensure 
that there can be no duplicate registrations when some of the servers 
are down or unreachable.

Thus address registration is subtle different than address assignment, 
and the design center for DHCP is the latter.
(But still investigating what can be done using DHCP.)

    Erik