Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Ole Trøan <otroan@employees.org> Wed, 05 September 2012 08:07 UTC

Return-Path: <ichiroumakino@gmail.com>
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 D192C21F8699 for <dhcwg@ietfa.amsl.com>; Wed, 5 Sep 2012 01:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GRg2dPepkIf for <dhcwg@ietfa.amsl.com>; Wed, 5 Sep 2012 01:07:02 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B019E21F8698 for <dhcwg@ietf.org>; Wed, 5 Sep 2012 01:06:49 -0700 (PDT)
Received: by eekb45 with SMTP id b45so90218eek.31 for <dhcwg@ietf.org>; Wed, 05 Sep 2012 01:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=kb0cNQWD6H1HpbZ+4Z7vq7rE55epb1QL1dAArZ5D1YM=; b=cOChat3qPPxsu2aCxEPwnSJxB/V6PGIosxZ+Q/CDb9/6h60g7ewjqPnNPRDeORY6+6 BM2rtKHWBO+QwiUhuHlrwUFgmRjtWi78xwtydt5lfL6F8JGxXSdH3uAkd+3GANmoTbiO Pe7ZDQ/KF9QiNEVKZEEi2RfntBJnQoBecdr523qFs/p6Jc652PF4BDDHsWM5xFWyBuAF +v4HxFpn97ujlU8NXZXIxCkNzjwNJXaYwAaClxIgtWecOKv/Om5WDAmVj5QJMrlrPr9Z AIcrPPawCex7CNjq1ZysccC987vzT8rtck+ZbgFy7nTcBN4TbjjknUp6EMxMcHLxiIJw wS9w==
Received: by 10.14.215.197 with SMTP id e45mr29341862eep.36.1346832408906; Wed, 05 Sep 2012 01:06:48 -0700 (PDT)
Received: from ?IPv6:2001:420:44ff:fd17:ec30:b128:b467:6482? ([2001:420:44ff:fd17:ec30:b128:b467:6482]) by mx.google.com with ESMTPS id v3sm1982379eep.10.2012.09.05.01.06.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 01:06:47 -0700 (PDT)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_A7628528-45D6-45A5-93D9-9521995450FF"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Ole Trøan <otroan@employees.org>
In-Reply-To: <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com>
Date: Wed, 05 Sep 2012 10:06:42 +0200
Message-Id: <FC830748-7F37-4AAB-A843-B75576B27B84@employees.org>
References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <E666D4CA7557D04DB6B9B2BA6DC28F3D285C2A36F8@INBANSXCHMBSA3.in.alcatel-lucent.com> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org> <FDF07965-FE45-4A36-8563-EFD748351A39@nominum.com> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1278)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 05 Sep 2012 08:07:03 -0000

Ted,

>> I look at it differently. you are adding more complexity on functions that are not in the data path. in my book that isn't fate sharing.
> 
> How is this not on the data path?

the DHCP server is not on the data path. unless one follows the model described in 3633 where the DHCP server is on the PE router.

[...]

>> this is like saying that configuring OSPF on a router is a unsolved problem, just because it isn't done with DHCP. ;-)
> 
> No, if OSPF is how these routers are being configured, that's not what I think of as static configuration.   Is that in fact the case?   It's my understanding that there is no clean dynamic configuration mechanism that ties back to the address allocation system (that is, to DHCP). 

I might be missing something here. I don't understand how the aggregate route for a set of delegated prefixes is dynamic. when and how could all subscribers within a aggregate move?

> It seems to me that what we are talking about here is exactly analogous to what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of which seem to be good solutions that are widely deployed and work well for network providers.   If there's a better way, I'm all ears, but when I asked in the routing area, I got some pretty vague answers that sounded a lot like "it's configured statically."

hmm, I didn't think the IPv4 aggregate route was deduced or configured from DHCPv4 either. the deployments I'm aware of, the PE is always configured outside of DHCP with the IPv4 subnets / aggregate routes. what's the analogy?

cheers,
Ole