Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 2 Sep 2013 23:10:14 +0800

Hi Alex,

I can live with either way.

Best Regards,
Leaf

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, August 29, 2013 6:14 PM
To: Leaf Yeh
Cc: [email-masked]
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Hello Leaf,

Problem statement text in the solution draft is one possible alternative.

Another alternative is to start from scratch a problem statement draft that
would cover the pool-opt draft as well as others mentioned in the thread.

Not sure which way to go better.

Alex

Le 29/08/2013 11:52, Leaf Yeh a écrit :
> Indeed, the draft might need more text on the Problem Statement for 
> the convincing power & easy understanding ...
>
> I guess the PS text should focus on the requirement of route 
> aggregation on PE for the customer's PD prefixes and the possible 
> solutions ...
>
>
> Best Regards, Leaf
>
>
>
> -----Original Message----- From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Friday, August 23, 2013 10:48 PM To: [email-masked] Subject: Re:
> [dhcwg] Anyone interested in continuing 
> draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>
> Le 23/08/2013 14:29, Leaf Yeh a écrit : [...]
>> That sounds a new chapter of this draft. I suspect I will have a 
>> chance to join. :-) LOL :-)
>
> What would be the toc of this DHCPv6 Prefix Delegation and Relay 
> Problem Statement?
>
> Alex
>
>>
>>
>> Best Regards, Leaf
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
------
>> ------------------------------------------------------------ From:
>> [email-masked] [mailto:[email-masked]] On Behalf Of 
>> Bernie Volz (volz) Sent: Friday, August 23, 2013 7:20 PM To:
>> [email-masked] Cc: Ralph Droms; [email-masked] WG
>> Subject: Re: [dhcwg] Anyone interested in continuing 
>> draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>>
>> BTW - I think I may have indicated this before, but does this really 
>> avoid the need for configuration on the router (relay)? How are items 
>> such as the link-address and next hop (dhcp server) addresses 
>> configured (rfc 3315 has a multicast default)? So there is still a 
>> bunch of "manual" configuration required? Admittedly you do say "more 
>> automation" but not really sure that has a lot of value - perhaps we 
>> need
> a Dynamic Router Configuration BOF?
>>
>> - Bernie (from iPad)
>>
>> On Aug 23, 2013, at 2:15 AM, "[email-masked]"
>> <[email-masked]> wrote: Hi Roberta,
>>
>> Yes, as indicated in the document, manual configuration is an option. 
>> but it has its limits too.
>>
>> This proposal is a contribution to add more automation to network 
>> configuration without requiring an additional dynamic protocol to 
>> drive how aggregates are built in a router co-located with a 
>> requestor, and therefore interact in a more dynamic fashion with a 
>> routing protocol (e.g., drive route withdrawals, etc.).
>>
>> Of course, some routers can offer some features to optimize the size 
>> of routing tables and prevent from injecting (very) specific entries. 
>> But still this behavior is implementation-specific and does not 
>> provide the same aggregation level as the one proposed in this 
>> document.
>>
>> Unlike implementation-specific behaviors, this proposal is 
>> deterministic since it is fully controlled by the entity which has 
>> the full knowledge of prefix related states and network policies:
>> e.g., the server has the knowledge of prefix assignment, prefix 
>> assignment policies, prefix aggregates, etc.
>>
>> I confirm this option is not a per-customer configuration parameter.
>>
>> Cheers, Med
>>
>>
>> De : Roberta Maglione [mailto:[email-masked]] Envoyé : jeudi
>> 22 août 2013 22:31 À : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms; 
>> [email-masked] WG Objet : Re: [dhcwg] Anyone interested in continuing 
>> draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>>
>> Hello, Maybe I'm missing something here, but I'm struggling to see 
>> the value added by this new option in terms of route aggregation 
>> functionality. Today with IPv4 if I need to summarize some routes I 
>> manually configure on the router a summary/aggregate route and I 
>> announce it into the routing protocol. Moving to IPv6 you could do 
>> the same thing, I don't quite get what's wrong with that? You say you 
>> would like to have an automatic way to tell the PE to aggregate the 
>> routes, but if I understand correctly the proposal what you are doing 
>> here is only moving the configuration of the summary route from the 
>> PE to the DHCPv6 Server; what do you really save here? In addition 
>> the route aggregation is not a per customer configuration, it would 
>> be per box or per service configuration so why do you want to add it 
>> to customers' profile in DCHPv6 Server?
>> Thanks Roberta
>>
>> On Thu, Aug 22, 2013 at 9:45 AM, <[email-masked]>
>> wrote: Re-,
>>
>> IMHO, draft-ietf-dhc-dhcpv6-agentopt-delegate does not cover the same 
>> objectives as in draft-ietf-dhc-dhcpv6-prefix-pool-opt.
>>
>> draft-ietf-dhc-dhcpv6-prefix-pool-opt aims to provide a dynamic means 
>> to trigger route advertisement actions and to control the route 
>> aggregates to be injected using a routing protocol. For example, a 
>> router can be told by the DHCP server to advertise an aggregate even 
>> if not all individual prefixes are assigned to customer located 
>> behind that router. This is a measure that can help in optimizing 
>> routing tables and avoid injecting very specific routes. Snooping the 
>> assignment and then guide the route advertisement actions may not be 
>> lead to the same optimized routing tables, because there will be 
>> "holes"
> that will prevent aggregating routes.
>>
>> Having an explicit channel like the one specified in 
>> draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO.
>>
>> Cheers, Med
>>
>>
>>> -----Message d'origine----- De : [email-masked] 
>>> [mailto:[email-masked]] De la part de Ralph Droms Envoyé
>>> : jeudi 22 août 2013 14:48 À : Alexandru Petrescu Cc :
>>> [email-masked] WG Objet : Re: [dhcwg] Anyone interested in 
>>> continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt?
>>>
>>>
>>> On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu 
>>> <[email-masked]> wrote:
>>>
>>>> Hi,
>>>>
>>>> One point I think is essential is the installment of routes in the 
>>>> DHCP Relay upon Prefix Assignment.
>>>>
>>>> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP 
>>>> must install a route in the DHCP Relay upon delegation.
>>>>
>>>> This draft seems to at least assume it, and to describe much more 
>>>> about it: how various parts of assigned prefixes are aggregated and
>>> communicated.
>>>>
>>>> I support it.
>>>
>>> After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to 
>>> have been aimed at the same problem.  If I have that right, it might 
>>> be instructive to review the dhc WG mailing list discussion that 
>>> lead to the abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate.
>>>
>>> - Ralph
>>>
>>>>
>>>> Alex
>>>>
>>>> Le 21/08/2013 14:41, [email-masked] a écrit :
>>>>> Hi Tomek,
>>>>>
>>>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt
>>>>> documents a useful feature in order to have more automation and 
>>>>> also control routes aggregation instead of relying on proprietary 
>>>>> behaviors of each implementation. Of course, part of these 
>>>>> objectives can be achieved if routes are installed manually or use 
>>>>> an out of band mechanism to enforce routing aggregation policies. 
>>>>> Still, the proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is 
>>>>> superior because the DHCP server has the knowledge of the prefix 
>>>>> assignments; and therefore routes can be triggered with dhcpv6 .
>>>>>
>>>>> A way to progress with this document is to target the Experimental 
>>>>> track. Based on the experience that will be gained in real 
>>>>> deployments, the status can be revisited if required.
>>>>>
>>>>> Cheers, Med
>>>>>
>>>>>> -----Message d'origine----- De : [email-masked] 
>>>>>> [mailto:[email-masked]] De la part de Tomek Mrugalski 
>>>>>> Envoyé : lundi 19 août 2013 16:52 À : dhcwg Objet
>>>>>> : [dhcwg] Anyone interested in continuing
>>>>>> draft-ietf-dhc-dhcpv6- prefix-pool-opt?
>>>>>>
>>>>>> During Berlin meeting chairs asked if there is still interest in 
>>>>>> the prefix-pool-option. There was nobody interested in the work 
>>>>>> in the room. The unanimous consensus in the room was to drop it. 
>>>>>> I just wanted to confirm that on the list.
>>>>>>
>>>>>> If you are interested in this work, want to support it and 
>>>>>> participate in it, please let us know by replying to the mailing 
>>>>>> list. Otherwise we'll drop this work and mark that draft as a 
>>>>>> dead WG document.
>>>>>>
>>>>>> Please respond within 2 weeks (until Sep. 2nd).
>>>>>>
>>>>>> Bernie & Tomek
>>>>>> _______________________________________________ dhcwg mailing 
>>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>>>> _______________________________________________ dhcwg mailing list 
>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________ dhcwg mailing list 
>>>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>> _______________________________________________ dhcwg mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________ dhcwg mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>
>> _______________________________________________ dhcwg mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>
>> _______________________________________________ dhcwg mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>
>
>
> _______________________________________________ dhcwg mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 16 Sep 2013 18:12:01 +0200

On 19.08.2013 16:52, Tomek Mrugalski wrote:
> During Berlin meeting chairs asked if there is still interest in the
> prefix-pool-option. There was nobody interested in the work in the room.
> The unanimous consensus in the room was to drop it. I just wanted to
> confirm that on the list.
> 
> If you are interested in this work, want to support it and participate
> in it, please let us know by replying to the mailing list. Otherwise
> we'll drop this work and mark that draft as a dead WG document.
> 
It seems that the discussion is more or less concluded as there were no
new comments posted in a long time. It seems clear that this work does
not have a WG consensus. There was a strong opposition to move this
document forward. There was minimal support for it in its current form.
As such, the chair chose to mark this document as dead WG item.

This does not mean that the problem the draft was trying to solve
magically disappeared. One of the suggestions made was to try to write a
clear problem statement. If people involved in this work are willing to
pursue this problem further, that is the recommended way to go.

I'd also like to point out that a dead draft is not really irreversibly
dead. If the envisaged problem statement draft is well written and well
received, perhaps people will change their mind about this solution and
decide that prefix-pool is worth pursuing after all. It is possible to
revive it later and change its state to something more alive.
Alternatively, some other solutions may emerge from the discussions
about problem statement.

Bernie and Tomek