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

"Leaf Yeh" <> Fri, 23 August 2013 12:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49E0311E82F1 for <>; Fri, 23 Aug 2013 05:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vrlBMmLhjhFH for <>; Fri, 23 Aug 2013 05:29:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::229]) by (Postfix) with ESMTP id 601CC11E81B9 for <>; Fri, 23 Aug 2013 05:29:39 -0700 (PDT)
Received: by with SMTP id r10so634399pdi.0 for <>; Fri, 23 Aug 2013 05:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=CceFBMeT7FgV6+s5LS4K7gr95/quC3ZKriycJx38PUY=; b=Aa2uTSEgQE/F8fr4sPO1SXIGPKj4M9Dn1UaNoUrRIhNAwJE2d3iTjd9YCS3ZbEceTi sAVU6x10kSv+eGNrojgHFRRw0kI2ztL3Wb8zG9X2eN5eDah1E7XH/AC/mB2jphMLCdX4 BZv9vAUUouRRIWWy3y39ordcLpJ7FUFy+bPnjEwFzANKPxLCQ3ncMuF2WRK3gj5fxNQ5 c/rKzE4HaWSlm89uy1ZNcUXjgj2Ka70weQCvOTXYagPKKfIIljMUzS40N6AG1NKaCeuj ex0sKzi4tp/vJDp4271sRqjhZITwzgrEs3U9gBSkglHhwKUaggSaZfO6YP/rzVPJWP/a SjJw==
X-Received: by with SMTP id we6mr2802767pbc.174.1377260979105; Fri, 23 Aug 2013 05:29:39 -0700 (PDT)
Received: from PC ([]) by with ESMTPSA id nj9sm21261879pbc.13.1969. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 05:29:38 -0700 (PDT)
From: "Leaf Yeh" <>
To: "'Bernie Volz \(volz\)'" <>, <>, "'Ole Troan'" <>
References: <> <> <> <> <> <>, <> <>
In-Reply-To: <>
Date: Fri, 23 Aug 2013 20:29:29 +0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6fdpRhGuGPQP+RSnWxWYU0EMRErAATdE+gAAuV46EAADNqYA==
Content-Language: zh-cn
Cc:, 'Ralph Droms' <>
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Aug 2013 12:29:40 -0000

BV> 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?

Those parameters mentioned above sounds the static part of configuration on
the relay (at PE router). In fact of  parameter configuration, link-address
of the relay could be IPv6 Link-Local address, you might not need to
configure it; though 'next hop (dhcp server) addresses' of the relay is a
must for manual configuration or through a ready management tool.

BV> Dynamic Router Configuration BOF?

That sounds a new chapter of this draft. I suspect I will have a chance to
join. :-) LOL :-)

Best Regards,

From: [] On Behalf Of
Bernie Volz (volz)
Sent: Friday, August 23, 2013 7:20 PM
Cc: Ralph Droms; WG
Subject: Re: [dhcwg] Anyone interested in continuing

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, ""
<> 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.
De : Roberta Maglione [] 
Envoyé : jeudi 22 août 2013 22:31
Cc : Ralph Droms; WG
Objet : Re: [dhcwg] Anyone interested in continuing
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?
On Thu, Aug 22, 2013 at 9:45 AM, <> wrote:

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.


>-----Message d'origine-----
>De : [] De la part de
>Ralph Droms
>Envoyé : jeudi 22 août 2013 14:48
>À : Alexandru Petrescu
>Cc : WG
>Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-
>On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu
><> 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
>> 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, 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 :
>>>> [] 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
>>> _______________________________________________ dhcwg mailing list
>> _______________________________________________
>> dhcwg mailing list
>dhcwg mailing list
dhcwg mailing list
dhcwg mailing list