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

[Ralph Droms <[e-mail]>]

Bernie - thanks for the clarifications.

I'm curious about the demand for this option.  Is there explicit demand from a group of SPs that want to use this option, or is being defined in speculation of SP demand?  Is it really the case that the SP may dynamically change the prefix delegation architecture in a dynamic way that requires this specific automated configuration?

In my opinion, piggy-backing the prefix-pool option on client-server communication is not appropriate.  As you point out, piggy-backing may not provide relay-router/server communication at the time it is needed.  Also, if I read the draft correctly and the relay-router snoops the server->client message to determine how to interpret the prefix-pool-opt, I think it would be much cleaner to include the operation code in the prefix-pool-opt itself.  If I recall correctly from the discussion of agentopt-delegate, there were questions about the reliability of piggy-backing: suppose messages are delivered out-of-order or delivered through different relay agents?

Someone else pointed out that there are many other configuration knobs that need to be set in the relay-router.  Why use DHCP just for the prefix routing and not the other configuration?

Has the alternative of a routing protocol been considered?

- Ralph

On Aug 22, 2013, at 6:12 AM 8/22/13, Bernie Volz (volz) <[e-mail]> wrote:

> Ralph:
> 
> Thanks for bringing up that old draft! There were issues here that caused this work to be abandoned.
> 
> And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I think one difference in the prefix-pool is that this is more to handle the case where the relay (router) is told to inject X/48 into the routing instead of Y/64 or Y/60 that might be going to the client. (This it to avoid having to inject lots of /64 or /60 routes when many clients are 'connected via the router'.)
> 
> Agentop could have been used to do that, but I'm not sure that was explicitly discussed or covered (and I didn't check the draft).
> 
> I did like agentop better than this proposal in one respect - and that is its use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrible idea (IMHO) since there is nothing to guarantee communication on which to piggyback the request to remove the pool. A lifetime covers that as it causes the entry to expire on its own. And, 0 lifetimes can be used to remove 'now'. But that's more of a minor issue as to whether the entire work is appropriate.
> 
> Cable CMTS devices have been snooping address and PD assignments for a long time now and rather successfully. I suspect that the 'prefix pool' issue there is handled by static configuration on the CMTS.
> 
> - Bernie
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ralph Droms
> Sent: Thursday, August 22, 2013 8:48 AM
> To: Alexandru Petrescu
> Cc: [e-mail] WG
> Subject: 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