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

[Alexandru Petrescu <[e-mail]>]

Le 04/09/2012 18:32, Ole Trøan a écrit :
> 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.

In a sense I agree - this proposal seems to still require snooping.
(i.e. existing single prefixes in PD require snooping and pool-opt draft
requires it too).

> this is most typically done with static configuration today.

Well no, static configuration at Relay is not sufficient for PD to work,
even if we dont talk pool-opt draft - there is a need of that route at
Relay.  There is no other solution to that than DHCP Relay to become
more intelligent (i.e. "snoop").

Alex

>
> cheers, Ole
>
>
>
> _______________________________________________ dhcwg mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>