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

Nick Hilliard <nick@foobar.org> Wed, 22 January 2014 23:06 UTC

Return-Path: <nick@foobar.org>
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 641971A0192 for <v6ops@ietfa.amsl.com>; Wed, 22 Jan 2014 15:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 GeJ3q7N0D_uY for <v6ops@ietfa.amsl.com>; Wed, 22 Jan 2014 15:06:21 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C1EED1A0242 for <v6ops@ietf.org>; Wed, 22 Jan 2014 15:06:20 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s0MN6APH051217 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 23:06:16 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org
Message-ID: <52E04EE0.8090409@foobar.org>
Date: Wed, 22 Jan 2014 23:06:08 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <CAEmG1=rRYwJaZp3qYF47=263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com> <71B4A0D3-B4F2-4B3C-B38E-ED7678BEA6FE@nominum.com> <CAEmG1=pfg74Xz8MbdRSpMaBJ8P1doHje=01ekBmL1U8_JR9P-g@mail.gmail.com> <CAKD1Yr344=nGC=_+2ar5v9V81mAAoB-Fk4Xu92cG5FTSOrHiKA@mail.gmail.com> <52E014C7.1090707@foobar.org> <CAKD1Yr1AXKaop3UoY2uKUvwDQORuBBhn7O4YVkwDTn5dA-Khtg@mail.gmail.com>
In-Reply-To: <CAKD1Yr1AXKaop3UoY2uKUvwDQORuBBhn7O4YVkwDTn5dA-Khtg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org" <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: Wed, 22 Jan 2014 23:06:23 -0000

On 22/01/2014 19:24, Lorenzo Colitti wrote:
> I don't think that's a useful line of reasoning. You argue that I and
> people like me cause endless arguments, but I could just as well argue that
> you and people like you are causing the endless arguments are the people
> who are constantly calling for the specifications to change to support
> their views.

That's how the IETF works: people perceive a need and make a proposal and
have been doing so for a dhcpv6 defgw/routing option for several years.
The reason it comes up regular as rain is that many people think it's a
sensible thing to do.

The difference in this situation is that one way or another, what I and
others are suggesting will make exactly no difference whatsoever to how you
want to run your networks, because you can continue to run your networks
with RAs and SLAAC unimpeded and will be able to continue to do so in future.

On the other hand, your position is that we should not have this
standardised component to configure our networks in the way we see fit: not
now, not ever.  It is incredibly frustrating to be at the receiving end of
this position.

> We've been through this before. I do accept that it's better in your
> network (though perhaps not in Matt's; ECMP does seem a better solution). I
> just don't agree that standardizing routing in DHCP to make your network
> work better is the right tradeoff for the Internet as a whole. The way I
> see it, changing the standards has knock-on effects on host implementations
> and other networks, and I believe that if you look at the system as a
> whole, it will be a net loss.

The proposal in itself does not have knock-on implications.  It's just a
dhcp option like ntp- or dns-server, end of story.

Defining a set of semantics so that it can interoperate sensibly with RAs
will take a modest amount of work.  draft-ietf-v6ops-dhcpv6-slaac-problem
will be an important part of this.  What's important is that it's
completely doable.

Nick