Re: [dhcwg] [RTG-DIR] DHCPv6 Prefix Pool Option

Alexandru - On a DHCP Relay, there would be a need to set up a route relative to a delegated prefix.

Definitely there should be a route associated to the delegated prefix on PE router for the customer/subscriber network. Here the draft (OPTION_PREFIX_POOL) is talking about how to aggregate those routes for customer networks as per the information of the prefix pool, when the PE router acts as the DHCPv6 relay agent.

Acee - the BRAS server that is maintaining
> subscriber DHCP state should have a configured aggregation policy for
> the DHCP prefix pool route. This problem has already been solved in
> commercial BRAS servers...

Yes, BRAS can do the route aggragation per the information of prefix pool when it has the distributed DHCPv6 server running on it.

But unfortunately it hasn't the explicit information about the prefix pool when it acts as the DHCPv6 relay. The information of the prefix pool are maintained in the centralized DHCPv6 server in the target scenario case discussed in the draft (OPTION_PREFIX_POOL). I suppose many operator including the major of MSO metwork and some Telecom network, employ this scenario case in their deployed network.

Best Regards,

Leaf

________________________________
From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Alexandru Petrescu [alexandru.petrescu@gmail.com]
Sent: Friday, August 03, 2012 4:36
To: dhcwg@ietf.org
Subject: Re: [dhcwg] [RTG-DIR] DHCPv6 Prefix Pool Option

Responding to this is on my todo list since MAastricht I believe - sorry
for having missed other opportunities.

On a DHCP Relay, there would be a need to set up a route relative to a
delegated prefix.

I need to better understand the context and then I will give more review
of this document.

Alex

Le 02/08/2012 12:47, Acee Lindem a écrit :
> Hi, I'm not sure what I was thinking this morning when I said that
> the DHCP server should run a routing daemon and advertise the
> aggregate route. Rather, the BRAS server that is maintaining
> subscriber DHCP state should have a configured aggregation policy for
> the DHCP prefix pool route. This problem has already been solved in
> commercial BRAS servers and there is no need to add a generic route
> advertisement mechanism to DHCP. Thanks, Acee
>
> On Aug 2, 2012, at 3:34 PM, Adrian Farrel wrote:
>
>> Hi,
>>
>> At the Routing Area meeting this morning, Ted raised some potential
>> DHCP work that routing folk should look at. Comments ideally go to
>> the DHC working group or back to Ted.
>>
>> Adrian
>>
>>> -----Original Message----- From: Ted Lemon
>>> [mailto:Ted.Lemon@nominum.com] Sent: 02 August 2012 20:11 To:
>>> adrian@olddog.co.uk Subject: DHCPv6 Prefix Pool Option
>>>
>>> Thanks for the time at the mic this morning.   The document I
>>> wanted you to comment on or solicit comment on is the DHCPv6
>>> Prefix Pool Option draft:
>>>
>>> http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt
>>>
>>> There was a question at the mic about why the DHCP server
>>> wouldn't inject the route itself, which I think is a good
>>> question, and could be argued to be the
>> right
>>> thing to do.   However, operationally there are a lot of missing
>>> pieces to
>> this-the
>>> DHCP server now becomes, in addition to being a DHCP server, also
>>> a publisher
>> of
>>> routes, and has to have information about the routing topology of
>>> the ISP that
>> I
>>> think might be nontrivial to maintain.
>>>
>>> The advantage of the current approach, which is improved by this
>>> new draft, is that it piggybacks on top of the existing
>>> relationship between the relay agent
>> and
>>> the DHCP server, which is required for DHCP to work.   The DHCP
>>> server now does not have to know the topology of the network-it
>>> sends the prefix aggregation information to the router, which
>>> presumably already has that information, by way of the DHCP
>>> relay, which is typically co-located in the
>> router.
>>>
>>> So despite my protestations of innocence at the mic, I suppose I
>>> do really
>> think
>>> it's a reasonable way to solve this particular problem.
>>
>
>
>
> _______________________________________________ routing-discussion
> mailing list routing-discussion@ietf.org
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

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