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

[Roberta Maglione <[e-mail]>]

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

On Sun, Aug 25, 2013 at 11:51 AM, Leaf Yeh <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Roberta Maglione
> Sent: Saturday, August 24, 2013 2:52 AM
> To: [e-mail]
> Cc: [e-mail] 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, <[e-mail]> 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:[e-mail]]
> Envoyé : jeudi 22 août 2013 22:31
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Ralph Droms; [e-mail] 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, <[e-mail]> 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 : [e-mail] [mailto:[e-mail]] De la part de
> >Ralph Droms
> >Envoyé : jeudi 22 août 2013 14:48
> >À : Alexandru Petrescu
> >Cc : [e-mail] 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
> ><[e-mail]> 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, [e-mail] 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 : [e-mail]
> >>>> [mailto:[e-mail]] 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 [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/dhcwg
> >>> _______________________________________________ dhcwg mailing list
> >>> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> dhcwg mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dhcwg
> >
> >_______________________________________________
> >dhcwg mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
>