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

Roberta Maglione <robmgl.ietf@gmail.com> Sun, 25 August 2013 22:04 UTC

Return-Path: <robmgl.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 61C4411E80F2 for <dhcwg@ietfa.amsl.com>; Sun, 25 Aug 2013 15:04:28 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 7NkfAbVOQJcL for <dhcwg@ietfa.amsl.com>; Sun, 25 Aug 2013 15:04:26 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F111211E80D5 for <dhcwg@ietf.org>; Sun, 25 Aug 2013 15:04:19 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id r11so880829lbi.18 for <dhcwg@ietf.org>; Sun, 25 Aug 2013 15:04:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m2cFVK69MYSYAkoCG3QxPRcz5x2EP2voCi884Sms70M=; b=YseXBrhIvz8mZhtKrKt1+Jh7n3ZxGJhy1HXdkQiMK6DTn0M/Z40WMIA9t9FUSWnlgE h0on6nWveDXXH+BfgHo9EgnaCoPn+FlwOCJaoZm9i6pZ14pZWjx06atGGY7C1JFCW+Se EY2oM5NKSa+qv17Wnt0/23UTy435+FRrcZzvlhNUZDp8Nl42/XIXts4kTVeIIwzq4G9s DxrsCdIdlYpItIB+CG1D/qvibkhTNB+jMVxw+BhlPZvZHhYQ8uh31voF9ZhMsb/m8rJ2 cQLODoZgGb6p0kFnhiZa+jcgMMKYsFjkNt3Hmh6iaUf8yqpHqX3HImq6FxE0wGFY9e3a Gk/w==
MIME-Version: 1.0
X-Received: by 10.152.8.12 with SMTP id n12mr10740756laa.10.1377468258782; Sun, 25 Aug 2013 15:04:18 -0700 (PDT)
Received: by 10.112.30.203 with HTTP; Sun, 25 Aug 2013 15:04:18 -0700 (PDT)
In-Reply-To: <521a2824.41a3440a.1475.4b84@mx.google.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> <521a2824.41a3440a.1475.4b84@mx.google.com>
Date: Sun, 25 Aug 2013 18:04:18 -0400
Message-ID: <CAKOT5Kq=knEgF_GE+oYQjQWkKt_Oqkuxpy+u0mg+E7C4Y=v4ng@mail.gmail.com>
From: Roberta Maglione <robmgl.ietf@gmail.com>
To: Leaf Yeh <leaf.yeh.sdo@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c365b641120204e4ccd2f8
Cc: "dhcwg@ietf.org WG" <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 22:04:28 -0000

Hello Leaf,
thanks for your comments please see inline [RM]
Best Regards
Roberta

On Sun, Aug 25, 2013 at 11:51 AM, Leaf Yeh <leaf.yeh.sdo@gmail.com> wrote:

>
> 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.
>
> [RM] The main difference here is that RAAN option was used to provide
> per-client configuration/route while if I understand correctly your
> proposal this option will be used to configure a per-box/per-relay route or
> per-group of users (per-service) route on the relay as both you and Med
> confirmed.


> 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.
>
> [RM]  This is my point: you repeat the same option in every Relay-reply
> message  in order to do a one time/per-relay configuration in my opinion
> this does not seem to be very efficient, but I may be wrong.




> 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.
>
> [RM] My point was  not about the packet length, but more mode of
> operation: you are asking the Relay to process multiple times the same
> option in order to install a route that is already there.


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