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

[Leaf yeh <[e-mail]>]

Ole - we did try with the use of the RAAN option.


General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The draft adopts roughly the same design idea as that of OPTION_RAAN, no new DHCPv6 message here.


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


The explanation from Ted about the routing aspect is thorough. We all know discussion on OSPF is not in the scope of this draft.

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The draft proposed the PE router to add (or withdraw) one more route (called as the aggregation route) per OPTION_PREFIX_POOL. The routing protocol (such as OSFP, ISIS) enabled on the network-facing interface of the PE router helps to advertise this additional route to the ISP core network.



Best Regards,
Leaf


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ole Tr?an
Sent: Wednesday, September 05, 2012 2:03 AM
To: Ted Lemon
Cc: [e-mail]
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

>> 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