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

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Sun, 25 August 2013 15: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 4501321F9D46 for <dhcwg@ietfa.amsl.com>; Sun, 25 Aug 2013 08:52:07 -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 60QUBk7bSsGC for <dhcwg@ietfa.amsl.com>; Sun, 25 Aug 2013 08:52:06 -0700 (PDT)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id E51D321F9D35 for <dhcwg@ietf.org>; Sun, 25 Aug 2013 08:52:05 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id g10so2495375pdj.40 for <dhcwg@ietf.org>; Sun, 25 Aug 2013 08:52:05 -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=jkmx+KF7ldso36O63Mn6LYKsHy45W6e+Ku7wGoLJgmA=; b=mtjd4aco52SoQY8rO6mxDYpyHhaz/L9kZGuaT2sWeTjNrd7EdnDH6ci3sXKhaxYULg K8UXG689x9zDyd3kzP/Wal6juanQDTqFpnH8fveLF6nHqIns8DOxQtyPlEuCVv90byPQ u/LpPBJlhHeKxvlzcNsPqtCV3o+ng8wiJdnmLW9JeTwEje9Z8/FAL3+V4Gbe64mtK3jx +mUsYr6dadQWC4BTK6PhTlnjItfcSAwNOkF2fiLp3smvQKGSbOp3cIc0nIwSlzZBCUeC K0ej4ihH/BWbd6AXyrktU3fz8LEgv274tD3b/XV1kZNv0Fh+rr+lZIXeDjH5QjJT6q8U h5Sg==
X-Received: by 10.68.135.101 with SMTP id pr5mr892188pbb.196.1377445925588; Sun, 25 Aug 2013 08:52:05 -0700 (PDT)
Received: from PC ([114.248.227.178]) by mx.google.com with ESMTPSA id yg1sm12605031pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 25 Aug 2013 08:52:04 -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> <94C682931C08B048B7A8645303FDC9F36EEEE4E6DB@PUEXCB1B.nanterre.francetelecom.fr> <CAKOT5Krz8FKHUDGuRO2K7qfQx8ZkGZa9=m2mBfmNjM0gE5jP8Q@mail.gmail.com>
In-Reply-To: <CAKOT5Krz8FKHUDGuRO2K7qfQx8ZkGZa9=m2mBfmNjM0gE5jP8Q@mail.gmail.com>
Date: Sun, 25 Aug 2013 23:51:54 +0800
Message-ID: <521a2824.41a3440a.1475.4b84@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6gMdlP7dDUrXHAQFydxeaL3b9KSwAAbO9Q
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: Sun, 25 Aug 2013 15:52:07 -0000

Roberta - I understand that in DHCP Server there are already some global parameters like the pool of addresses to be used for the clients, but my understanding of DHCP behavior , and please correct me if I’m wrong, is that the DHCP Server provides a per-client configuration.

Not sure you have interest to read draft (RAAN, draft-ietf-dhc-dhcpv6-agentopt-delegate) again. 
I believe Bernie (or Tomek) have better answer for this question.


Roberta - How would it work with this new option? How does the DHCP Server know if it has to add or not this option if it is not based on client profile or on client request?

The OPTION_PREFIX_POOL will be included in the Relay-Reply message for DHCPv6-PD Reply to the clients. 
Pls. read the draft (OPTION_PREFIX_POOL) for the details, Madam.


Roberta - Do you plan to insert the option in all  the DHCP Server replies/to all clients? 

Yes, almost every Relay-Reply message for Reply to the clients as described in the draft. 


Roberta - I assume the router is going to install the route once and what does it do if it gets the same routes more the one? Just ignore? 

Read the draft, keep in mind you have a smart PE with strong CPU. :-)


Roberta - It seems like a waste of cycles on the router.

The OPTION_PREFIX_POOL proposed by the draft to include in the Relay-Reply message is not more than 22 bytes with a fixed format. 
Your concern here sounds not a problem.


Roberta - In my opinion having global parameters on DHCP Server seems  a major change in the DHCP model.

The DHCPv6 server already has the ‘global parameters’, such as the prefix pool … as you mentioned above. 
The draft (OPTION_PREFIX_POOL) does intend to enhance the (deployment) capability of DHCPv6 server. Pls. read my last reply mail to you & Med's mail again. 
The solution with a newly defined option is a solution we thought with a minimal protocol change. 
New capability from the new protocol design do need a little change on your habit for the employment in your deployment.



Best Regards,
Leaf



----------------------------------------------------------------------------------------------------------------------------------------
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Roberta Maglione
Sent: Saturday, August 24, 2013 2:52 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?

Hi Med, Leaf,
I fully understand the requirement for network automation versus manual configuration, but I still don’t think defining a new dhcp option is the right direction to go in order to do routes aggregations in a router. 
As somebody else already pointed out here, if you need a way to automatically interact with the router i2rs is the right place to discuss your requirements.
In addition you said:
➢  I confirm this option is not a per-customer configuration parameter.
 If it is not a per-client configuration why  would you like to use DHCP for that?
I understand that in DHCP Server there are already some global parameters like the pool of addresses to be used for the clients, but my understanding of DHCP behavior , and please correct me if I’m wrong, is that the DHCP Server provides a per-client configuration.
How would it work with this new option? How does the DHCP Server know if it has to add or not this option if it is not based on client profile or on client request?
Do you plan to insert the option in all  the DHCP Server replies/to all clients? 
I assume the router is going to install the route once and what does it do if it gets the same routes more the one? Just ignore? It seems like a waste of cycles on the router.
In my opinion having global parameters on DHCP Server seems  a major change in the DHCP model.
Thanks
Roberta

On Fri, Aug 23, 2013 at 2:15 AM, <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