Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

[Leaf yeh <[e-mail]>]

Alex - > One alternative solution may be to have a mechanism by which the Relay 
> itself first executes Requesting Router (before being a Relay) to 
> obtain that short prefix, at which point we no longer talk 'snooping'.  
> This could be the Prefix Pool Option without snooping.
Ole - I'm more in favour of that too. the Relay acts as a DHCP client and requests a "static route / prefix pool / aggregate route" whatever we choose to call that option.

The above sounds the mechanism introduced in 'draft-ietf-dhc-dhcpv6-tunnel-01' (https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-tunnel/ ), to introduce DHCPv6 client on the PE router particularly for the aggregation route (or prefix pool). But draft (OPTION_PREFIX_POOL) only use the similar existing tech, bulk leasequery, for the case of power cycle occurred on the relay.

Draft (OPTION_PREFIX_POOL) proposes the solution called 'Piggyback', which has the benefit to make it easier to sync the 'status' of prefix pools (or aggregation routes) on the relay with that indicated on the server.


Best Regards,
Leaf


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ole Tr?an
Sent: Monday, September 10, 2012 5:03 PM
To: Alexandru Petrescu
Cc: [e-mail]
Subject: Re: [dhcwg] Comments on some aspects on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Alex,

[...]

> One alternative solution may be to have a mechanism by which the Relay 
> itself first executes Requesting Router (before being a Relay) to 
> obtain that short prefix, at which point we no longer talk 'snooping'.  
> This could be the Prefix Pool Option without snooping.

I'm more in favour of that too. the Relay acts as a DHCP client and requests a "static route / prefix pool / aggregate route" whatever we choose to call that option.

you would still need snooping to populate the RIB in the Relay itself though.

cheers,
Ole