Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

[Ole Trøan <[e-mail]>]

Ted,

>> This would not have the overhead per transaction and also the handling at the relay would be much elegant and simpler.
>> Current draft requires relay to implement bulk lease query and additional processing per relayed PD request.
> 
> The overhead per transaction here is a bit of a red herring—we're talking about thirteen bytes, if I count correctly. 
> 
> Furthermore, the working group already went down the path of separating out the transactions a couple of years ago, and determined that there were synchronization problems; that work was eventually dropped for lack of interest.
> 
> The problem remains unsolved; this is actually a pretty good solution, because it involves fate sharing, with a netconf solution wouldn't have, and uses an established communications path, which netconf/yang doesn't offer.

fate sharing of what? the client functions independently of whatever aggregate route there is for a whole block of subscribers. this just adds another cog in the machinery that may fail.

> This is definitely better than the solution vendors are currently offering, which is to simply sniff the prefixes from DHCP messages to the client.   With my working group chair hat off, I'm in favor of doing this work precisely because it solves the problem neatly, and no better solution has ever been presented of which I'm aware.

this does not solve the DHCPv6 PD problem of route injection. a route needs to be installed per client, and snooping is still needed for that. this proposal _only_ solves the problem of installing an aggregate route for multiple PD RRs into a PE/relay. this is most typically done with static configuration today.

cheers,
Ole