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

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

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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms
Sent: Wednesday, September 05, 2012 4:12 AM
To: Lemon Ted; Ole Trøan
Cc: dhcwg@ietf.org 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 <otroan@employees.org>
> 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
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg