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

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Thu, 22 August 2013 16:23 UTC

Return-Path: <leaf.yeh.sdo@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 F3A9011E80ED for <dhcwg@ietfa.amsl.com>; Thu, 22 Aug 2013 09:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Wl2cs8bMQHWi for <dhcwg@ietfa.amsl.com>; Thu, 22 Aug 2013 09:23:45 -0700 (PDT)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9F11E81C5 for <dhcwg@ietf.org>; Thu, 22 Aug 2013 09:23:44 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id y10so2066113pdj.39 for <dhcwg@ietf.org>; Thu, 22 Aug 2013 09:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=lqes1rW1S50d/h3BtvSahKFuIepWR4R2+BUMAmez2aA=; b=Qj8v0ULk7ZlOX8bOPQ1gAdBHArmETKeu9WU0fksyV0X+szpqjN0z8uOLAb0kv52YNg wNiYsvbxwclYSNHsyy5wa8yRvv8ZPZHEUjOzbsrxZDn7XKKkEHX/q09eBm5WObKBmSRg 2MYKVELYPJ/RCnfcxRIWAnuhPCvIs+yqkpcOCUzl8skkoKwYw4KrNhw79z78JQ+9uP7+ zTf0T+TIRsWPyw9sWzonq5AEejJC6H4aRBqURZi1T3/lzplI3oz3Yx1JhfrQXX8rVuHF YhuDA6Qiv+56gTTdLG8eDUj/Wofr0tCUwk+brrAzjuJIlv3O3pylneNZJ0Hh08N1bjjx 5KQA==
X-Received: by 10.69.13.132 with SMTP id ey4mr14274743pbd.52.1377188624307; Thu, 22 Aug 2013 09:23:44 -0700 (PDT)
Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id dg3sm15816457pbc.24.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 09:23:43 -0700 (PDT)
From: "Leaf Yeh" <leaf.yeh.sdo@gmail.com>
To: "'Bernie Volz \(volz\)'" <volz@cisco.com>, "'Ralph Droms'" <rdroms.ietf@gmail.com>, "'Alexandru Petrescu'" <alexandru.petrescu@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>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com>
Date: Fri, 23 Aug 2013 00:23:36 +0800
Message-ID: <52163b0f.83b3440a.3854.6129@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOnzXvaLHmSLwSfkSFfLi6OLbc0pmhMawAgAAuoZA=
Content-Language: zh-cn
Cc: 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: Thu, 22 Aug 2013 16:23:47 -0000

BV> 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).

No. This question has been answered in Med's mail.


BV> ...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'.

Lifetime of the prefix pool will be the new concept on the server, though it
might be easy to derive from leases of those active PD prefixes in the pool.


This draft already has the following words:
<t> The PE router acting as the relay agent MAY set up a table for the
   lease or status of the prefix pools on it according to the leases of
   the delegated customer prefixes within the prefix pools.  The lease
   of the prefix pool SHOULD dynamically set to be the maximum lease of
   the delegated customer prefix within it.
</t>

The flag of the pool is designed for including the status of 'Active' or
'Released', which sounds 0=active=add the aggregation route, or
1=released=remove the aggregation route. 


BV> But that's more of a minor issue as to whether the entire work is
appropriate.

Anyway, we will rethink (or revisit) your technical suggestion.


BV> 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.

I guess the issue of static configuration is still there on the CMTS. 
This question has been also answered in Med's mail.


Best Regards,
Leaf




-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Bernie Volz (volz)
Sent: Thursday, August 22, 2013 9:12 PM
To: Ralph Droms; Alexandru Petrescu
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg