Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

Ted Lemon <ted.lemon@nominum.com> Thu, 19 December 2013 14:05 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4B51ADF26 for <v6ops@ietfa.amsl.com>; Thu, 19 Dec 2013 06:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 tLnxI2rTcMnP for <v6ops@ietfa.amsl.com>; Thu, 19 Dec 2013 06:05:05 -0800 (PST)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5751ADBCE for <v6ops@ietf.org>; Thu, 19 Dec 2013 06:05:05 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUrL9D2u5IrhYYWJ+KQzvWbPPuthSdUWv@postini.com; Thu, 19 Dec 2013 06:05:03 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 84E811B82E9 for <v6ops@ietf.org>; Thu, 19 Dec 2013 06:05:03 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 77D58190043; Thu, 19 Dec 2013 06:05:03 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Dec 2013 06:05:03 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <CAKD1Yr3aeHu=4wy8NcRvT_bX9OdCE5PZ-JqJGZrxgVsi+uOK4w@mail.gmail.com>
Date: Thu, 19 Dec 2013 09:05:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6F8010C6-D8A3-49F9-AEA2-67527DCC02E3@nominum.com>
References: <alpine.OSX.2.00.1311271353550.3903@ayourtch-mac> <1386274786.29351.YahooMailNeo@web142501.mail.bf1.yahoo.com> <alpine.OSX.2.00.1312060759220.68814@ayourtch-mac> <1386378082.99914.YahooMailNeo@web161901.mail.bf1.yahoo.com> <alpine.OSX.2.00.1312072028290.68814@ayourtch-mac> <F024FF5B-35A6-4221-952C-4A730A68C59D@delong.com> <D437C864-F276-46A6-A51E-4C57E5CF829E@cisco.com> <52B22828.6080700@inex.ie> <CAKD1Yr3TA9+yDpCRHNMOXNiq0bZ0x-yn=kVotiFD2187GjdnWw@mail.gmail.com> <52B2ED1E.1040108@inex.ie> <CAKD1Yr2hQBB_gsv6=zRLq6SmxF6JG=o2DT=-iDykSz7u=yJVZg@mail.gmail.com> <273B4FE5-E311-4327-8B04-13467AF9D72F@nominum.com> <CAKD1Yr3aeHu=4wy8NcRvT_bX9OdCE5PZ-JqJGZrxgVsi+uOK4w@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 14:05:07 -0000

On Dec 19, 2013, at 8:47 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> Sure! That's the DHCP way. Make the configuration procotol completely static, then realize that failures cause outages, and then be build redundancy into your services because you've chosen a client communication protocol that doesn't allow updates. Awesome :-)

I was being slightly ironic, but also sort of serious, in the sense that the thing you are saying DHCP fails at, that requires additional complexity, is essentially the same problem as needs to be addressed for homenets: how to do routing when there's more than one default router.   Although in a _very limited_ sense this is solved in the single-homed dual-router RA case, the problem as a whole is unsolved.   If it were solved, we would not need VRRP in the dual-router single-home single-failure case.

I'm not saying we should try to solve it here, merely pointing out that the case you are making has wider implications, and that in fact even with RA, your hosts will be happier if you are running VRRP during the outage scenario you describe.