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

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

>> 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.
> 
> Fate sharing in the sense that the DHCP server is best able to know from what aggregate prefix prefixes for clients on a particular router will be allocated, and the DHCP packet is the way these prefixes get allocated to the client.   So we can be sure that if the network is working at all, it will be working completely.

I look at it differently. you are adding more complexity on functions that are not in the data path. in my book that isn't fate sharing.

>> 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.
> 
> It solves half the problem: configuring the route that the router advertises.   You are correct that it doesn't solve the other half—figuring out where to send packets downstream.   But actually, snooping the DHCP packet is a perfectly good solution for this problem; what is lacking is a standard that says how it's done. 

we did try with the use of the RAAN option.

> What snooping is _not_ good for is figuring out what route to advertise upstream.   To say that the upstream route is currently done with static configuration is synonymous with saying that the problem is currently unsolved.

this is like saying that configuring OSPF on a router is a unsolved problem, just because it isn't done with DHCP. ;-)

cheers,
Ole