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

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Thu, 29 August 2013 09:52 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 A0C7721F9E3A for <dhcwg@ietfa.amsl.com>; Thu, 29 Aug 2013 02:52:42 -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 gciRW9T+8Jog for <dhcwg@ietfa.amsl.com>; Thu, 29 Aug 2013 02:52:41 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8339221F856A for <dhcwg@ietf.org>; Thu, 29 Aug 2013 02:52:41 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id lf1so708471pab.10 for <dhcwg@ietf.org>; Thu, 29 Aug 2013 02:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=GJFdO3ptDQXsHaVmtRH9LnRKLdbG98x7XQBETMC90Fk=; b=ogv+vVUC0fSaoppqaiXW/VQ0PLHsf7uFSv8+GtzwA6NRKu72AI+8wSCB1phDZSeOLG L7SO29WhKe0YxNIuhKxSt7wXISzkxl14ASrlygOYUgdqprb4xwwtHP6sNuXnx4L+Tdr+ rwDJ4Nv2KOD7/XEnzgXgFur5R/q9bZNEXP+y0kEH//0Z+Qy3agtWSv1YBxulNgvG5iZe ZCoqxmSJ5elMsKrq8y0rgifrneBwvoTHoCyR1CFj+cKk0vNew5Rtw0A4JKMZLuxkDb7z IPatpwLK8+lA4nt/RkoCMLhvUkR8wOv7POMCn/CXVKJL67zv4V8bL4h9RYsq3AyyuvFU PmTA==
X-Received: by 10.68.194.104 with SMTP id hv8mr2549348pbc.168.1377769957533; Thu, 29 Aug 2013 02:52:37 -0700 (PDT)
Received: from PC ([114.248.227.178]) by mx.google.com with ESMTPSA id ia5sm36845566pbc.42.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 02:52:36 -0700 (PDT)
From: "Leaf Yeh" <leaf.yeh.sdo@gmail.com>
To: "'Alexandru Petrescu'" <alexandru.petrescu@gmail.com>, <dhcwg@ietf.org>
References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEEE4E649@PUEXCB1B.nanterre.francetelecom.fr> <CAKOT5Kr_Ve+9taH_AmhUp1HwHY=ggytVjUuToMf2Wr4oKoozOQ@mail.gmail.com>, <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <7B81A958-9434-46B6-973A-D4BD7F2C424F@cisco.com> <521755b2.69d4440a.4d0d.ffff8e59@mx.google.com> <5217763C.8010702@gmail.com>
In-Reply-To: <5217763C.8010702@gmail.com>
Date: Thu, 29 Aug 2013 17:52:29 +0800
Message-ID: <521f19e4.05c3440a.2ddc.ffff826b@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: Ac6gD+XCgGiM91qiS0ioVT2YHuvqZQAB7kTw
Content-Language: zh-cn
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, 29 Aug 2013 09:52:42 -0000

Indeed, the draft might need more text on the Problem Statement for the
convincing power & easy understanding ...

I guess the PS text should focus on the requirement of route aggregation on
PE for the customer's PD prefixes and the possible solutions ...


Best Regards,
Leaf



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Alexandru Petrescu
Sent: Friday, August 23, 2013 10:48 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Le 23/08/2013 14:29, Leaf Yeh a écrit :
[...]
> That sounds a new chapter of this draft. I suspect I will have a 
> chance to join. :-) LOL :-)

What would be the toc of this DHCPv6 Prefix Delegation and Relay Problem
Statement?

Alex

>
>
> Best Regards,
> Leaf
>
>
>
> ----------------------------------------------------------------------
> ------
> ------------------------------------------------------------
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf 
> Of Bernie Volz (volz)
> Sent: Friday, August 23, 2013 7:20 PM
> To: mohamed.boucadair@orange.com
> Cc: Ralph Droms; dhcwg@ietf.org WG
> Subject: Re: [dhcwg] Anyone interested in continuing 
> draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>
> BTW - I think I may have indicated this before, but does this really 
> avoid the need for configuration on the router (relay)? How are items 
> such as the link-address and next hop (dhcp server) addresses 
> configured (rfc 3315 has a multicast default)? So there is still a 
> bunch of "manual" configuration required? Admittedly you do say "more 
> automation" but not really sure that has a lot of value - perhaps we need
a Dynamic Router Configuration BOF?
>
> - Bernie (from iPad)
>
> On Aug 23, 2013, at 2:15 AM, "mohamed.boucadair@orange.com"
> <mohamed.boucadair@orange.com> wrote:
> Hi Roberta,
>
> Yes, as indicated in the document, manual configuration is an option. 
> but it has its limits too.
>
> This proposal is a contribution to add more automation to network 
> configuration without requiring an additional dynamic protocol to 
> drive how aggregates are built in a router co-located with a 
> requestor, and therefore interact in a more dynamic fashion with a 
> routing protocol (e.g., drive route withdrawals, etc.).
>
> Of course, some routers can offer some features to optimize the size 
> of routing tables and prevent from injecting (very) specific entries. 
> But still this behavior is implementation-specific and does not 
> provide the same aggregation level as the one proposed in this document.
>
> Unlike implementation-specific behaviors, this proposal is 
> deterministic since it is fully controlled by the entity which has the 
> full knowledge of prefix related states and network policies: e.g., 
> the server has the knowledge of prefix assignment, prefix assignment 
> policies, prefix aggregates, etc.
>
> I confirm this option is not a per-customer configuration parameter.
>
> Cheers,
> Med
>
>
> De : Roberta Maglione [mailto:robmgl.ietf@gmail.com] Envoyé : jeudi 22 
> août 2013 22:31 À : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; 
> dhcwg@ietf.org WG Objet : Re: [dhcwg] Anyone interested in continuing 
> draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>
> Hello,
> Maybe I'm missing something here, but I'm struggling to see the value 
> added by this new option in terms of route aggregation functionality.
> Today with IPv4 if I need to summarize some routes I manually 
> configure on the router a summary/aggregate route and I announce it 
> into the routing protocol. Moving to IPv6 you could do the same thing, 
> I don't quite get what's wrong with that?
> You say you would like to have an automatic way to tell the PE to 
> aggregate the routes, but if I understand correctly the proposal what 
> you are doing here is only moving the configuration of the summary 
> route from the PE to the DHCPv6 Server; what do you really save here?
> In addition the route aggregation is not a per customer configuration, 
> it would be per box or per service configuration so why do you want to 
> add it to customers' profile in DCHPv6 Server?
> Thanks
> Roberta
>
> On Thu, Aug 22, 2013 at 9:45 AM, <mohamed.boucadair@orange.com> wrote:
> Re-,
>
> IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same 
> objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt.
>
> draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means 
> to trigger route advertisement actions and to control the route 
> aggregates to be injected using a routing protocol. For example, a 
> router can be told by the DHCP server to advertise an aggregate even 
> if not all individual prefixes are assigned to customer located behind 
> that router. This is a measure that can help in optimizing routing 
> tables and avoid injecting very specific routes. Snooping the 
> assignment and then guide the route advertisement actions may not be 
> lead to the same optimized routing tables, because there will be "holes"
that will prevent aggregating routes.
>
> Having an explicit channel like the one specified in 
> draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO.
>
> Cheers,
> Med
>
>
>> -----Message d'origine-----
>> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De la 
>> part de Ralph Droms Envoyé : jeudi 22 août 2013 14:48 À : Alexandru 
>> Petrescu Cc : dhcwg@ietf.org WG Objet : 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
>
> _______________________________________________
> 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