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

[Alexandru Petrescu <[e-mail]>]

Le 05/09/2012 05:16, Leaf yeh a écrit :
> Ralph - One issue that comes to mind for me is that the DHCPv6 server
> may not, in fact, have complete information about the routing and
> prefix aggregation information.

I tend to agree with this statement.

> The DHCPv6 server would be inferring aggregation information from
> the pools of prefixes it has to delegate.  Looked at another way,
> there is likely an oracle of network configuration somewhere from
> which the delegated prefix pools and prefix aggregation for routing
> is derived. The DHCPv6 server might be able to make an educated guess
> but it doesn't have necessarily authoritative information.

I wonder about the implementation of educated guess...

Given a set of prefixes find their common longest prefix (easy) and make
sure its other subprefixes are not in use elsewhere (more difficult.)

I mean I dont think an educated guess could be done reasonably to form a
common prefix and instruct the Relay about it.  Even less that Relay to
advertise the aggregated prefix instead of numerous specific routes.

But I agree there may be a problem in too numerous specific routes
advertised by Relay to routers, about the dynamically delegated prefixes.

Alex

>
>
> General Idea Clarification on the draft (OPTION_PREFIX_POOL):  If we
>  are only thinking about the delegated prefix to customer and its
> pre-configured prefix pool on the DHCPv6 server (or DR), the server
> does know all the lease of the delegated prefix, then can definitely
>  derive the status ('Active' or 'Released') of the prefix pool. There
>  is no 'educated guess' here. Because the server acts as the manager
>  (or administrator) of all the pools, he authorize (or delegate) the
>  prefix to the customer, and know all the information (or aspects) of
>  the delegated prefixes.
>
>
> Ralph - Another issue with piggybacking is that the routing
> information may change independent of any specific DHCPv6 message
> exchanges (someone else raised this issue), so that there would be no
> way to send updates if there was no DHCPv6 traffic to send through
> the router.
>
>
> General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The
> draft creates somewhat of new reasonable function on the server to
> support the policy change (for route aggregation based on the
> information of the prefix pools), the basic proposal in the draft is
>  to utilize the process of 'Prefix Delegation Reconfiguration' to
> trigger the immediately update. See Section 6 of the draft.
>
>
> Ralph - Why would this aggregation information not be provided
> through whatever configuration mechanism is used to manage the
> router?
>
>
> General Idea Clarification on the draft (OPTION_PREFIX_POOL):
> DHCPv6-PD works closely with the prefix pools, (which always mean the
> necessary aggregation route in Ole's static configuration,) it could
> be the simplest way to do the dynamic parameter provisioning to PE
> router.
>
>
>
> Best Regards, Leaf
>
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Ralph Droms Sent:
> Wednesday, September 05, 2012 4:12 AM To: Lemon Ted; Ole Trøan Cc:
> [e-mail] WG Subject: Re: [dhcwg] Call for Adoption:
> draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
>
>
> On Sep 4, 2012, at 3:32 PM 9/4/12, Ted Lemon wrote:
>
>> On Sep 4, 2012, at 2:02 PM, Ole Trøan <[e-mail]>
>> wrote:
>>> 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.
>>
>> How is this not on the data path?
>>
>>> we did try with the use of the RAAN option.
>>
>> Right, but this wasn't useful because it added no functionality-the
>> only purpose it served was to avoid having the relay agent look in
>> the client part of the DHCP packet.   I never understood why you
>> guys wanted this.   If you think the work is important, I am
>> certainly not opposed to reviving it, though-it was a perfectly
>> good draft.
>>
>>> this is like saying that configuring OSPF on a router is a
>>> unsolved problem, just because it isn't done with DHCP. ;-)
>>
>> No, if OSPF is how these routers are being configured, that's not
>> what I think of as static configuration.   Is that in fact the
>> case?   It's my understanding that there is no clean dynamic
>> configuration mechanism that ties back to the address allocation
>> system (that is, to DHCP).
>>
>> It seems to me that what we are talking about here is exactly
>> analogous to what's done today in IPv4 with DHCP snooping and DHCP
>>  leasequery, both of which seem to be good solutions that are
>> widely deployed and work well for network providers.   If there's
>> a better way, I'm all ears, but when I asked in the routing area,
>> I got some pretty vague answers that sounded a lot like "it's
>> configured statically."
>
> One issue that comes to mind for me is that the DHCPv6 server may
> not, in fact, have complete information about the routing and prefix
>  aggregation information.  The DHCPv6 server would be inferring
> aggregation information from the pools of prefixes it has to
> delegate.  Looked at another way, there is likely an oracle of
> network configuration somewhere from which the delegated prefix pools
> and prefix aggregation for routing is derived.  The DHCPv6 server
> might be able to make an educated guess but it doesn't have
> necessarily authoritative information.
>
> Another issue with piggybacking is that the routing information may
> change independent of any specific DHCPv6 message exchanges (someone
>  else raised this issue), so that there would be noway to send
> updates if there was no DHCPv6 traffic to send through the router.
>
> Why would this aggregation information not be provided through
> whatever configuration mechanism is used to manage the router?
>
> - Ralph
>
>>
>> _______________________________________________ dhcwg mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________ dhcwg mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________ dhcwg mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>
>