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

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Fri, 23 August 2013 07: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 56C911F0ED5 for <dhcwg@ietfa.amsl.com>; Fri, 23 Aug 2013 00:52:26 -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=[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 gcaLZRauwVhA for <dhcwg@ietfa.amsl.com>; Fri, 23 Aug 2013 00:52:15 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id CB5C71F0D57 for <dhcwg@ietf.org>; Fri, 23 Aug 2013 00:52:15 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id r10so370641pdi.28 for <dhcwg@ietf.org>; Fri, 23 Aug 2013 00:52:15 -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=/kWdYwIbJwRQe7h5Q6Wdi7N1H++s7Ly7DIbhAVbqOKk=; b=bDkUVEVvp16K/0GWlvYHf1zywB1CA1zvo10dZsByfiIcWI/MPEFOJkKu6C+bZq54wP pkTkRFDyKeGGfZlF/yfSK9QFTrhQB/O2GlH3JnXR5c7Q8r5GcWhZ4+Q+bUiyhnYl3SWf 8kXS0hfSz9INsqC4rLvOq6uuEH2QzKj9YXPVY2BqJBgT0BCfShMf0Ov8fzmdYx04g0Yj dPjZwWmyii04KvMvp7IMfYOp5uHx4JjyRO472eNTHh9XSZhwhmQxloslQIAl+bufKbHx Ko1juZNN43vixxwT0wrGxiReG6Cst6ICLucGjNsBcfrEebuiphwtvZsl/BaumAyiUzIl v2Vg==
X-Received: by 10.66.26.132 with SMTP id l4mr9778520pag.138.1377244335505; Fri, 23 Aug 2013 00:52:15 -0700 (PDT)
Received: from PC ([111.193.212.125]) by mx.google.com with ESMTPSA id br3sm1789398pbd.31.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 00:52:14 -0700 (PDT)
From: "Leaf Yeh" <leaf.yeh.sdo@gmail.com>
To: "'Roberta Maglione'" <robmgl.ietf@gmail.com>, <mohamed.boucadair@orange.com>
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>
In-Reply-To: <CAKOT5Kr_Ve+9taH_AmhUp1HwHY=ggytVjUuToMf2Wr4oKoozOQ@mail.gmail.com>
Date: Fri, 23 Aug 2013 15:52:06 +0800
Message-ID: <521714ae.e302450a.21db.6884@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: Ac6fdphFWKpf3nEhQX+HSdrz/9YSUQAP/mmA
Content-Language: zh-cn
Cc: dhcwg@ietf.org, 'Ralph Droms' <rdroms.ietf@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: Fri, 23 Aug 2013 07:52:27 -0000

Roberta - ... I don’t quite get what’s wrong with that?

If operator can't see the advantage of OPTION_PREFIX_POOL, he can still live
with the manual configuration for aggregation route on the PE router. The
draft just propose a new DHCPv6 option, operator could choose  whether or
not to employ it. But I guess you will need route aggregation on most of
your PE router, if you employ DHCPv6-PD for your IPv6 deployment.


Roberta - ... 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?

That sounds the difference between the static (or manual) and the dynamic.
In the network scenario of centralized DHCPv6 server and distributed relay
agent, operator could deploy aggregation route automatic & dynamically on
each relay (or PE router) by the DHCPv6 server while employing
OPTION_PREFIX_POOL, and not by the manual & static configuration on each of
them.

As you know, the server has all the information about the customer's address
plan. If  the DHCPv6 server employs the OPTION_PREFIX_POOL, operator could
also get the additional capability to revise the address plan for customers,
such as renumbering; or adjust the size of prefix pool on the DHCPv6 server
(as the centralized deployment).


Roberta - ... why do you want to add it to customers’ profile in DCHPv6
Server?

As mentioned above, DHCPv6 server not only has information about customer's
profile (eg. the lease & its' status of each customers prefix), but also has
information about the address plan for customers (eg. the associated prefix
pools)). We  could try to define new concept on lease, lifetime or status of
the prefix pool (eg. for the dynamic aggregation route @ PE router), to
enhance the deployment capability of DHCPv6 server.


Best Regards,
Leaf



----------------------------------------------------------------------------
-------------------------------------------------------------
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Roberta Maglione
Sent: Friday, August 23, 2013 4:31 AM
To: mohamed.boucadair@orange.com
Cc: dhcwg@ietf.org WG; Ralph Droms
Subject: 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