Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Ted Lemon <Ted.Lemon@nominum.com> Wed, 21 August 2013 15:51 UTC

Return-Path: <Ted.Lemon@nominum.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 C438F11E8268 for <dhcwg@ietfa.amsl.com>; Wed, 21 Aug 2013 08:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.587
X-Spam-Level:
X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqWgU3E74y09 for <dhcwg@ietfa.amsl.com>; Wed, 21 Aug 2013 08:51:39 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 00D3B11E8255 for <dhcwg@ietf.org>; Wed, 21 Aug 2013 08:51:38 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUhTiCtwxANi9st5oVsqLUwjP4HMnIPXu@postini.com; Wed, 21 Aug 2013 08:51:39 PDT
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 671C51B827E for <dhcwg@ietf.org>; Wed, 21 Aug 2013 08:51:38 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (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 ESMTPS id 4D06719006E; Wed, 21 Aug 2013 08:51:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 08:51:38 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
Thread-Index: AQHOnmvOZd/9qOMClEKacKJnLzUg1JmgG/6AgAApJwA=
Date: Wed, 21 Aug 2013 15:51:38 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525FA8A@mbx-01.win.nominum.com>
References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com>
In-Reply-To: <5214BF85.8020509@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8408F4DD60ADE9449C0EEB26BDD4CACC@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
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, 21 Aug 2013 15:51:45 -0000

On Aug 21, 2013, at 6:24 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
> One point I think is essential is the installment of routes in the DHCP
> Relay upon Prefix Assignment.
> 
> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP must
> install a route in the DHCP Relay upon delegation.
> 
> This draft seems to at least assume it, and to describe much more about
> it: how various parts of assigned prefixes are aggregated and communicated.

I think that it might be helpful to have a document that simply describes the problem, and talks about what is currently being done to solve it, and then suggests Leaf's solution as another possibility.   This might actually be more helpful than the solution document, because it would allow us to talk about the problem without first agreeing on a solution.

Would you be willing to work with Leaf on such a document?

(I'm not promising that the working group will adopt it, of course—just saying that I think it might be interesting.)