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

Ralph Droms <rdroms.ietf@gmail.com> Mon, 26 August 2013 17:29 UTC

Return-Path: <rdroms.ietf@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 EA69611E81D6 for <dhcwg@ietfa.amsl.com>; Mon, 26 Aug 2013 10:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NUNqlYhZSTxV for <dhcwg@ietfa.amsl.com>; Mon, 26 Aug 2013 10:29:40 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0111E81C8 for <dhcwg@ietf.org>; Mon, 26 Aug 2013 10:29:39 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id c11so1908986qcv.41 for <dhcwg@ietf.org>; Mon, 26 Aug 2013 10:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQPsAnHqg5mOE8AjEgrVP2570I4ndQdy5C2i6xrKYMg=; b=vfaggU+XYMd2FObz6DRJTyTH1NobMKQaowA+ITBC0//IWFxTNN+qBJIUkVmtS6pNRd PoMDyew55a6t7yBQ3gxPK28OT1gN5v7UHtv4cyNeLJYDZ5UzIxMO78pezazx9zCwJlOm YID1r/9USbHRgUA799tJiZbgadj+7qQSyvVKckDFeG6Ud+705fkddiAkRKSf3DmIa2rR nNniq7QMV1c1BfgPrHXdyqllMXlCYjE7eAvXLHM3DpiKyn23jnUGIl77IPh4xKGVLoiL 5rq/pImaSaUL9WC2KJ091R018UCnebWIl4/gKPe5eUBJ4x1ZGDMYCAHGUU5Tb4Ly6fdz +yVQ==
X-Received: by 10.224.92.70 with SMTP id q6mr17737420qam.43.1377538179210; Mon, 26 Aug 2013 10:29:39 -0700 (PDT)
Received: from che-vpn-cluster-2-418.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id m10sm23305082qae.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 10:29:37 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com>
Date: Mon, 26 Aug 2013 10:29:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com>
References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com>
To: Bernie Volz (volz) <volz@cisco.com>
X-Mailer: Apple Mail (2.1508)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
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: Mon, 26 Aug 2013 17:29:41 -0000

Bernie - thanks for the clarifications.

I'm curious about the demand for this option.  Is there explicit demand from a group of SPs that want to use this option, or is being defined in speculation of SP demand?  Is it really the case that the SP may dynamically change the prefix delegation architecture in a dynamic way that requires this specific automated configuration?

In my opinion, piggy-backing the prefix-pool option on client-server communication is not appropriate.  As you point out, piggy-backing may not provide relay-router/server communication at the time it is needed.  Also, if I read the draft correctly and the relay-router snoops the server->client message to determine how to interpret the prefix-pool-opt, I think it would be much cleaner to include the operation code in the prefix-pool-opt itself.  If I recall correctly from the discussion of agentopt-delegate, there were questions about the reliability of piggy-backing: suppose messages are delivered out-of-order or delivered through different relay agents?

Someone else pointed out that there are many other configuration knobs that need to be set in the relay-router.  Why use DHCP just for the prefix routing and not the other configuration?

Has the alternative of a routing protocol been considered?

- Ralph

On Aug 22, 2013, at 6:12 AM 8/22/13, Bernie Volz (volz) <volz@cisco.com> wrote:

> Ralph:
> 
> Thanks for bringing up that old draft! There were issues here that caused this work to be abandoned.
> 
> And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I think one difference in the prefix-pool is that this is more to handle the case where the relay (router) is told to inject X/48 into the routing instead of Y/64 or Y/60 that might be going to the client. (This it to avoid having to inject lots of /64 or /60 routes when many clients are 'connected via the router'.)
> 
> Agentop could have been used to do that, but I'm not sure that was explicitly discussed or covered (and I didn't check the draft).
> 
> I did like agentop better than this proposal in one respect - and that is its use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrible idea (IMHO) since there is nothing to guarantee communication on which to piggyback the request to remove the pool. A lifetime covers that as it causes the entry to expire on its own. And, 0 lifetimes can be used to remove 'now'. But that's more of a minor issue as to whether the entire work is appropriate.
> 
> Cable CMTS devices have been snooping address and PD assignments for a long time now and rather successfully. I suspect that the 'prefix pool' issue there is handled by static configuration on the CMTS.
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms
> Sent: Thursday, August 22, 2013 8:48 AM
> To: Alexandru Petrescu
> Cc: dhcwg@ietf.org WG
> Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
> 
> 
> On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
> 
>> Hi,
>> 
>> 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 support it.
> 
> After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have been aimed at the same problem.  If I have that right, it might be instructive to review the dhc WG mailing list discussion that lead to the abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate.
> 
> - Ralph
> 
>> 
>> Alex
>> 
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a écrit :
>>> Hi Tomek,
>>> 
>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a 
>>> useful feature in order to have more automation and also control 
>>> routes aggregation instead of relying on proprietary behaviors of 
>>> each implementation. Of course, part of these objectives can be 
>>> achieved if routes are installed manually or use an out of band 
>>> mechanism to enforce routing aggregation policies. Still, the 
>>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior because 
>>> the DHCP server has the knowledge of the prefix assignments; and 
>>> therefore routes can be triggered with dhcpv6 .
>>> 
>>> A way to progress with this document is to target the Experimental 
>>> track. Based on the experience that will be gained in real 
>>> deployments, the status can be revisited if required.
>>> 
>>> Cheers, Med
>>> 
>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org 
>>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski Envoyé 
>>>> : lundi 19 août 2013 16:52 À : dhcwg Objet : [dhcwg] Anyone 
>>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt?
>>>> 
>>>> During Berlin meeting chairs asked if there is still interest in the 
>>>> prefix-pool-option. There was nobody interested in the work in the 
>>>> room. The unanimous consensus in the room was to drop it. I just 
>>>> wanted to confirm that on the list.
>>>> 
>>>> If you are interested in this work, want to support it and 
>>>> participate in it, please let us know by replying to the mailing 
>>>> list. Otherwise we'll drop this work and mark that draft as a dead 
>>>> WG document.
>>>> 
>>>> Please respond within 2 weeks (until Sep. 2nd).
>>>> 
>>>> Bernie & Tomek _______________________________________________
>>>> dhcwg mailing list dhcwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> _______________________________________________ dhcwg mailing list 
>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg