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

[Alexandru Petrescu <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Bernie Volz (volz)
> Sent: Friday, August 23, 2013 7:20 PM
> To: [e-mail]
> Cc: Ralph Droms; [e-mail] 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, "[e-mail]"
> <[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
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>