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

Ole Troan <otroan@employees.org> Thu, 09 January 2014 10:26 UTC

Return-Path: <otroan@employees.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 2624E1AE246 for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2014 02:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 tCisRjauj0-Z for <v6ops@ietfa.amsl.com>; Thu, 9 Jan 2014 02:26:52 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id BE92C1AE1AE for <v6ops@ietf.org>; Thu, 9 Jan 2014 02:26:51 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAPB4zlKQ/khN/2dsb2JhbABZgwu6U4ENFnSCJQEBAQMBDlcSAgULC0ZXBogPCKp4mhEXjwUHgySBEwEDkDOZeYFvgT87
X-IronPort-AV: E=Sophos; i="4.95,630,1384300800"; d="asc'?scan'208"; a="2709302"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 09 Jan 2014 10:26:39 +0000
Received: from dhcp-lys02-vla252-10-147-116-56.cisco.com (dhcp-lys02-vla252-10-147-116-56.cisco.com [10.147.116.56]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s09AQcjf001818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jan 2014 10:26:39 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_B6E22C15-EC4D-41F4-8AE3-6FFF42F100D4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAKD1Yr3zfSU4g+OZfnJCvgHby5h7=gXBj15FnicsBzqd9ZYWHA@mail.gmail.com>
Date: Thu, 09 Jan 2014 11:26:37 +0100
Message-Id: <EEE6479E-A2E9-45F4-8FF5-269826B7B41C@employees.org>
References: <CAEmG1=rRYwJaZp3qYF47=263jFp+BLpF3H6PuS8+Fd6qinMT3g@mail.gmail.com> <24CFBACC-7994-47D2-AAC5-F4CCAB4B29D8@delong.com> <CAEmG1=o_9TVBtSqwm3MQVz5_BKTP83Kqc+bbGWYm-9aBDyRvfA@mail.gmail.com> <AAE3D266-11A3-4891-A099-781F92D49C1A@employees.org> <CAKD1Yr3zfSU4g+OZfnJCvgHby5h7=gXBj15FnicsBzqd9ZYWHA@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
X-Mailer: Apple Mail (2.1827)
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: Thu, 09 Jan 2014 10:26:53 -0000

> can I paraphrase the problem?
> "the problem is how to get hosts to load balance across multiple first-hop routers?"
> 
> That's an easy problem to solve - do ECMP on the hosts.

right.

> Unfortunately, though, I fear that the problem is "we want the IPv6 design to be the same as the IPv4 design we already have", and in general that's a problem that's impossible to solve without making IPv6 look the same as IPv4.

that's not a class of problem I think we're able to solve in the IETF.

I think it is a perfectly valid operational model to manually / statically configure hosts though. Router Discovery provides a dynamic way to discover a router for default, that handles multiple routers, adjusts dynamically as the network changes.
manual configuration doesn't do any of that, but that doesn't mean there isn't a place for manual configuration.
if operators want to configure the default route with something like Puppet or Netconf isn't that acceptable with you?
DHCP would just be another way to do manual configuration of static information to hosts.

if this was implemented in DHCP, and the expectation was that all hosts should support it,
how does the deployment model and transition phases look like?
e.g. you have a mixed link with some hosts supporting the option and some hosts that don't.
is static DHCP configuration mutually exclusive with router discovery?

cheers,
Ole