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

[Alexandru Petrescu <[e-mail]>]

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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Alexandru Petrescu Sent:
> Friday, August 23, 2013 10:48 PM To: [e-mail] 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:
>> [e-mail] [mailto:[e-mail]] On Behalf Of
>> Bernie Volz (volz) Sent: Friday, August 23, 2013 7:20 PM To:
>> [e-mail] Cc: Ralph Droms; [e-mail] 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, "[e-mail]"
>> <[e-mail]> 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:[e-mail]] Envoyé : jeudi
>> 22 août 2013 22:31 À : BOUCADAIR Mohamed IMT/OLN Cc : Ralph Droms;
>> [e-mail] 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, <[e-mail]>
>> 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 : [e-mail]
>>> [mailto:[e-mail]] De la part de Ralph Droms Envoyé
>>> : jeudi 22 août 2013 14:48 À : Alexandru Petrescu Cc :
>>> [e-mail] 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
>>> <[e-mail]> 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, [e-mail] 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 : [e-mail]
>>>>>> [mailto:[e-mail]] 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 [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
>>>
>>> _______________________________________________ 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
>>
>> _______________________________________________ dhcwg mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>>
>>
>
>
> _______________________________________________ dhcwg mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>