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

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 19 Aug 2013 16:52:00 +0200

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

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 21 Aug 2013 00:36:44 +0800

I believe the WG-draft (OPTION_PREFIX_POOL) does put forward a problem that
occurs in IPv6 deployment, which need route aggregation at the PE router.

The question about working interest here might include 3 parts of meaning:

1. Do we need a dynamic configuration mechanism for the route aggregation
here?

I guess some guys could live with the manual configuration for the route
aggregation here. In the ipv4 deployment, we always need configure IPv4
address for the associated interface on the router, which is in the same
subnet of the addresses assigned the CE or subscribers' hosts. 

The point of this draft is that we need automatic configuration mechanism
for the aggregated route on IPv6 router, while we are not necessary to
configure ipv6 address for the associated interface.

2. Do we need a mechanism tightly coupled with DHCPv6-PD (RFC3633)
mechanism?

The alternative solution might be that the relay could communicate with the
server independently with DHCPv6-PD, which sounds more general for each kind
of possible parameter on the router.  

The point of this draft is that router aggregation sounds only associated
with the DHCPv6-PD and its prefix pool. The newly defined option and its
associated mechanism could solve the problem in the easiest way, and not
introduced new DHCPv6 message; but the option will always be included in the
DHCPv6-PD message by the relay and the server.

3. Do we need a mechanism patented by Huawei?

It depends on what you read from the IPR disclosure
(https://datatracker.ietf.org/ipr/2051/ ) of Huawei. Per the message on the
web, my reading is that their terms are defensive and harmless if you don't
assert patent against Huawei, though the IPR disclosure looks too late.

Best Regards,
Leaf
(one of the authors)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomek Mrugalski
Sent: Monday, August 19, 2013 10:52 PM
To: dhcwg
Subject: [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.

Bernie & Tomek
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: <[email-masked]>
Date: Wed, 21 Aug 2013 14:41:39 +0200

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Aug 2013 15:24:21 +0200

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.

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.
>>
>> Bernie & Tomek _______________________________________________
>> dhcwg mailing list [email-masked]
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 21 Aug 2013 16:21:16 +0200

On 21.08.2013 14:41, [email-masked] wrote:
> 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 .
> 
No, sorry. That won't work. At least not as you'd like it to. Take a
look at IANA registry for DHCPv6 options:
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml.
It clearly states that assigning option codes require experts review
*and* standards action. Experimental drafts are not standards. You are
certainly welcome to proceed with this as experimental, but my
understanding of the process is that it would be published without
options assigned. And the draft (or experimental RFC) without option
code is really useless, because it is unlikely that any verndor would
implement it.

As a side comment, currently assigning the option code for DHCPv6
requires experts review. Let me cite the complete list: Ted Lemon. While
Ted Lemon is certainly a DHCPv6 expert, the standardization process
should not rely on a single person. If Ted becomes unavailable for
whatever reason (e.g. wins a lottery and decides to retire tomorrow on
his private island), we wouldn't get new DHCPv6 options any more.

I suppose that is something that should be corrected one day, probably
together with the registry name.

Tomek

---

From: <[email-masked]>
Date: Wed, 21 Aug 2013 16:41:39 +0200

Hi Tomek,

Yes, you are right. Forget about my proposal to change the intended status.

Cheers,
Med

>De : Tomek Mrugalski [mailto:[email-masked]]
>Envoyé : mercredi 21 août 2013 16:21
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : dhcwg
>Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-
>prefix-pool-opt?
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2013 15:15:18 +0000

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

Only standards-track documents can get DHCP options codes.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2013 15:51:38 +0000

> it: how various parts of assigned prefixes are aggregated and communicated.

I think that it might be helpful to have a document that simply describes the problem, and talks about what is currently being done to solve it, and then suggests Leaf's solution as another possibility.   This might actually be more helpful than the solution document, because it would allow us to talk about the problem without first agreeing on a solution.

Would you be willing to work with Leaf on such a document?

(I'm not promising that the working group will adopt it, of course—just saying that I think it might be interesting.)

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 Aug 2013 11:00:16 -0500

Hi Ted,

Isn't it not good to use DHCP options to establish routes? Remember what
happened to

draft-ietf-mif-dhcpv6-route-option-05 in mif?

I don't know if Leaf's document does it though.

Regards,

Behcet

On Wed, Aug 21, 2013 at 10:51 AM, Ted Lemon <[email-masked]> wrote:

> I think that it might be helpful to have a document that simply describes
> the problem, and talks about what is currently being done to solve it, and
> then suggests Leaf's solution as another possibility.   This might actually
> be more helpful than the solution document, because it would allow us to
> talk about the problem without first agreeing on a solution.
>
> (I'm not promising that the working group will adopt it, of course—just
> saying that I think it might be interesting.)
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Aug 2013 16:28:46 +0000

On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya <[email-masked]> wrote:
> Isn't it not good to use DHCP options to establish routes? Remember what happened to

It's not possible to get IETF consensus on a DHCP option to deliver routes to clients.   I never said it was an inherently bad idea.   The reason I asked MIF to stop working on it was that the endless floggings were getting in the way of doing real work.   Really, preventing us from doing real work at all.

This is a completely different situation—DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Aug 2013 10:17:20 +0200

Le 21/08/2013 18:28, Ted Lemon a écrit :
> It's not possible to get IETF consensus on a DHCP option to deliver
> routes to clients.   I never said it was an inherently bad idea. The
>  reason I asked MIF to stop working on it was that the endless
> floggings were getting in the way of doing real work.   Really,
> preventing us from doing real work at all.
>
> This is a completely different situation—DHCP relay agents _already_
> snoop DHCP messages to set up routing between PE and CPE devices.

It is this kind of snooping I refer to, and maybe less the explicit
indication from a server to install a particular route (which was
controversial in MIF).  This is a distinction which could be part of an 
document.

Alex

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 22 Aug 2013 18:55:21 +0800

Ted - This is a completely different situation-DHCP relay agents _already_
snoop DHCP messages to set up routing between PE and CPE devices.

I remember Ted has a discussion with WG-RTGWG on this topic in its session
of IETF84, and we had an additional discussion on the ML of
Routing-Discussion. Per these discussion records before and the personal
feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that
'use DHCPv6 to add & withdraw route on the PE router' will get rough
consensus (or will not irritate big controversy) in IETF.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
Sent: Thursday, August 22, 2013 12:29 AM
To: <[email-masked]>; Behcet Sarikaya
Cc: <[email-masked]>
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

happened to

It's not possible to get IETF consensus on a DHCP option to deliver routes
to clients.   I never said it was an inherently bad idea.   The reason I
asked MIF to stop working on it was that the endless floggings were getting
in the way of doing real work.   Really, preventing us from doing real work
at all.

This is a completely different situation-DHCP relay agents _already_ snoop
DHCP messages to set up routing between PE and CPE devices.

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 22 Aug 2013 13:50:14 +0200

I may easily be wrong here but snooping sounds to me like a stop gap
solution i.e. what you do when no better method is available?

Seen from outside (my chair) it looks like there might be a need for a
protocol to talk directly with the switch/router, possibly first passing
a control/admin system that controls what may be set up in various
places in the network.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Aug 2013 13:58:30 +0200

Le 22/08/2013 12:55, Leaf Yeh a écrit :
> Ted - This is a completely different situation-DHCP relay agents
> _already_ snoop DHCP messages to set up routing between PE and CPE
> devices.
>
> I remember Ted has a discussion with WG-RTGWG on this topic in its
> session of IETF84, and we had an additional discussion on the ML of
> Routing-Discussion. Per these discussion records before and the
> personal feedback from Adrian (RTG-AD), my conclusion (or impression)
> sounds that 'use DHCPv6 to add & withdraw route on the PE router'

Well yes and no, depends how it is expressed.

On one hand, the DHCP software on the Relay should insert a route
whenever a Prefix is allocated by PD - otherwise later application-layer
packets are not forwarded from that prefix through that Relay.  Maybe
the route entry should expire when the prefix lifetime expires.

PD through a Relayed topology is useless otherwise.  It would be as if
an address were allocated with DHCP but the firewall blocked that address.

On another hand, an explicit DHCP message to add routes (as seems to
imply the wording 'use DHCPv6 to add route on the PE router') approaches
more the meaning that may be controversial.  Because that is the typical
what routing protocols do, and in the particular case of default routes,
it is the typical action of ND.

Alex

> will get rough consensus (or will not irritate big controversy) in
> IETF.
>
>
> Best Regards, Leaf
>
>
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ted Lemon Sent:
> Thursday, August 22, 2013 12:29 AM To: <[email-masked]>; Behcet
> Sarikaya Cc: <[email-masked]> Subject: Re: [dhcwg] Anyone interested
>  in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
>
> This is a completely different situation-DHCP relay agents _already_

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Aug 2013 14:00:28 +0200

> a control/admin system that controls what may be set up in various

Sounds as if a combination of DHCP and another protocol be needed 
whenever DHCP PD is deployed in a DHCP Relay topology.

But something that describes the problem could indeed be written.

Alex

>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of
>> Ted Lemon
>> To:<[email-masked]>; Behcet Sarikaya
>> Cc:<[email-masked]>
>> On Aug 21, 2013, at 9:00 AM, Behcet Sarikaya<[email-masked]>  wrote:

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Aug 2013 14:14:37 +0200

> Sounds as if a combination of DHCP and another protocol be needed whenever DHCP PD is deployed in a DHCP Relay topology.
> 

like:

http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00

?

cheers,
Ole

---

From: [email-masked]
Date: Thu, 22 Aug 2013 08:21:50 -0400

> De : Sten Carlsen <[email-masked]>
> Seen from outside (my chair) it looks like there might be a need for
> a protocol to talk directly with the switch/router, possibly first 
> passing a control/admin system that controls what may be set up in 
> various places in the network.

Hum... a protocol that exchanges routes directly with a router? Over
a TCP connection maybe? We could even group the route information 
in Updates and per Address Family?  Add a few Capabilities over the
top and call it Novative Excellent Way for Border Gateway Programming?

Excuse the naive question, but isn't this BGP? I always get weird 
looks when I suggest we run BGP on DHCP servers, but it would 
actually fit the job description pretty well (at least for the 
purpose of route injection). 

/JF

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 22 Aug 2013 14:33:03 +0200

> http://tools.ietf.org/html/draft-stenberg-pd-route-maintenance-00
Something like this, though I may not agree to all the conclusions,
maybe because I don't run a large network.

One thing you do not mention here is the situation where one unit fails
(maybe because of an axe from an angry user) and must be replaced.
Mostly automatic reconfiguration seems a good thing in that situation.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 22 Aug 2013 14:35:14 +0200

> purpose of route injection). 
I am not familiar enough with BGP to answer that question. The thought
has occurred to me.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ralph Droms <[email-masked]>
Date: Thu, 22 Aug 2013 08:48:17 -0400

> it: how various parts of assigned prefixes are aggregated and communicated.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 22 Aug 2013 13:12:24 +0000

Ralph:

Thanks for bringing up that old draft! There were issues here that caused this work to be abandoned.

And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I think one difference in the prefix-pool is that this is more to handle the case where the relay (router) is told to inject X/48 into the routing instead of Y/64 or Y/60 that might be going to the client. (This it to avoid having to inject lots of /64 or /60 routes when many clients are 'connected via the router'.)

Agentop could have been used to do that, but I'm not sure that was explicitly discussed or covered (and I didn't check the draft).

I did like agentop better than this proposal in one respect - and that is its use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrible idea (IMHO) since there is nothing to guarantee communication on which to piggyback the request to remove the pool. A lifetime covers that as it causes the entry to expire on its own. And, 0 lifetimes can be used to remove 'now'. But that's more of a minor issue as to whether the entire work is appropriate.

Cable CMTS devices have been snooping address and PD assignments for a long time now and rather successfully. I suspect that the 'prefix pool' issue there is handled by static configuration on the CMTS.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Thursday, August 22, 2013 8:48 AM
To: Alexandru Petrescu
Cc: [email-masked] WG
Subject: 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.
> 

- Ralph

>>> [mailto:[email-masked]] De la part de Tomek Mrugalski Envoyé 
>>> : lundi 19 août 2013 16:52 À : dhcwg Objet : [dhcwg] Anyone 
>>> 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.
>>>

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 22 Aug 2013 21:22:38 +0800

Sten - ... snooping sounds to me like a stop gap solution .

Per my understanding about the implementation (or behavior) of the PE router
of today, it (or it's CPU) snoops & handles every protocol message in the
control (and management) plane in fact.

Best Regards,
Leaf

----------------------------------------------------------------------------
------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sten Carlsen
Sent: Thursday, August 22, 2013 7:50 PM
To: [email-masked]
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Seen from outside (my chair) it looks like there might be a need for a
protocol to talk directly with the switch/router, possibly first passing a
control/admin system that controls what may be set up in various places in
the network.

Best Regards,
Leaf

-----Original Message-----

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 22 Aug 2013 13:33:04 +0000

Leaf ... the relay technically isn't snooping. It is relaying (it has to process these messages -- they are not just going through the relay). The snooping part is that it is looking inside the client part of the message. This was what agentopt was trying to avoid (and also trying to permit slightly different information going to the relay -- not just what went to the client).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leaf Yeh
Sent: Thursday, August 22, 2013 9:23 AM
To: 'Sten Carlsen'; [email-masked]
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Per my understanding about the implementation (or behavior) of the PE router of today, it (or it's CPU) snoops & handles every protocol message in the control (and management) plane in fact.

Best Regards,
Leaf

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sten Carlsen

I may easily be wrong here but snooping sounds to me like a stop gap solution i.e. what you do when no better method is available?

Seen from outside (my chair) it looks like there might be a need for a protocol to talk directly with the switch/router, possibly first passing a control/admin system that controls what may be set up in various places in the network.

On 22/08/13 12:55, Leaf Yeh wrote:
Ted - This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices.

I remember Ted has a discussion with WG-RTGWG on this topic in its session of IETF84, and we had an additional discussion on the ML of Routing-Discussion. Per these discussion records before and the personal feedback from Adrian (RTG-AD), my conclusion (or impression) sounds that 'use DHCPv6 to add & withdraw route on the PE router' will get rough consensus (or will not irritate big controversy) in IETF.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, August 22, 2013 12:29 AM
To: <[email-masked]>; Behcet Sarikaya
Cc: <[email-masked]>
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

This is a completely different situation-DHCP relay agents _already_ snoop DHCP messages to set up routing between PE and CPE devices.

--
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: <[email-masked]>
Date: Thu, 22 Aug 2013 15:45:48 +0200

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

>Ralph Droms
>Envoyé : jeudi 22 août 2013 14:48
>À : Alexandru Petrescu
>Cc : [email-masked] WG
>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
>>

---

From: Sten Carlsen <[email-masked]>
Date: Thu, 22 Aug 2013 16:12:32 +0200

Also my understanding, "snooping" is normally used to describe that you
look into/listen to things that are not really meant for you.

My point was that giving information meant for consumption at that point
could provide better information than deducting what you need from
information that does not really contain what you may need.

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 22 Aug 2013 23:47:40 +0800

Sten - ."snooping" is normally used to describe that you look into/listen to
things that are not really meant for you.

I regard your understanding (or definition) is right.

Sten - . giving information meant for consumption at that point could
provide better information than deducting what you need from information
that does not really contain what you may need.

OPTION_PREFIX_POOL defined in this draft is targeted to the information
consumption point (or the relay agent @ PE router), which contains the
information of prefix pool (maintained by the server) for the aggregation
route.

Best Regards,
Leaf

----------------------------------------------------------------------
From: Sten Carlsen [mailto:[email-masked]] 
Sent: Thursday, August 22, 2013 10:13 PM
To: Bernie Volz (volz)
Cc: Leaf Yeh; [email-masked]
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Also my understanding, "snooping" is normally used to describe that you look
into/listen to things that are not really meant for you.

On 22/08/13 15:33, Bernie Volz (volz) wrote:
Leaf ... the relay technically isn't snooping. It is relaying (it has to
process these messages -- they are not just going through the relay). The
snooping part is that it is looking inside the client part of the message.
This was what agentopt was trying to avoid (and also trying to permit
slightly different information going to the relay -- not just what went to
the client).

- Bernie

-----Original Message-----
Leaf Yeh

Best Regards,
Leaf

Best Regards,
Leaf

-----Original Message-----

--
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!" 

-- 
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 22 Aug 2013 23:47:40 +0800

BV - ...the relay technically isn't snooping. It is relaying (it has to
process these messages -- they are not just going through the relay). The
snooping part is that it is looking inside the client part of the message.

Right.

BV - This was what agentopt was trying to avoid (and also trying to permit
slightly different information going to the relay -- not just what went to
the client).

We use the word of 'snoop' in this thread is supposed for the PD prefixes
(or CE's prefix) contained in OPTION_IA_PD. 
This draft (OPTION_PREFIX_POOL) has not employ the word of 'snoop' yet.

Best Regards,
Leaf

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Thursday, August 22, 2013 9:33 PM
To: Leaf Yeh; 'Sten Carlsen'; [email-masked]
Subject: RE: [dhcwg] Anyone interested in continuing

- Bernie

-----Original Message-----

Best Regards,
Leaf

Best Regards,
Leaf

-----Original Message-----

--
Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Aug 2013 16:07:26 +0000

On Aug 22, 2013, at 1:17 AM, Alexandru Petrescu <[email-masked]> wrote:
> controversial in MIF).  This is a distinction which could be part of an document.

I don't understand the point you are making.   There's no controversy about PD affecting routing, other than that the routing guys would ideally prefer to use a routing protocol for it.   But fate-sharing argues _for_ PD snooping, not against it.   So it's completely different than the discussion about default routes being delivered to end nodes.

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 23 Aug 2013 00:23:36 +0800

BV> Agentop could have been used to do that, but I'm not sure that was
explicitly discussed or covered (and I didn't check the draft).

No. This question has been answered in Med's mail.

BV> ...that is its use of lifetimes for the prefix. Prefix-pool's uses a
flag is a terrible idea (IMHO) since there is nothing to guarantee
communication on which to piggyback the request to remove the pool. A
lifetime covers that as it causes the entry to expire on its own. And, 0
lifetimes can be used to remove 'now'.

Lifetime of the prefix pool will be the new concept on the server, though it
might be easy to derive from leases of those active PD prefixes in the pool.

This draft already has the following words:
<t> The PE router acting as the relay agent MAY set up a table for the
   lease or status of the prefix pools on it according to the leases of
   the delegated customer prefixes within the prefix pools.  The lease
   of the prefix pool SHOULD dynamically set to be the maximum lease of
   the delegated customer prefix within it.
</t>

The flag of the pool is designed for including the status of 'Active' or
'Released', which sounds 0=active=add the aggregation route, or
1=released=remove the aggregation route. 

BV> But that's more of a minor issue as to whether the entire work is
appropriate.

Anyway, we will rethink (or revisit) your technical suggestion.

BV> Cable CMTS devices have been snooping address and PD assignments for a
long time now and rather successfully. I suspect that the 'prefix pool'
issue there is handled by static configuration on the CMTS.

I guess the issue of static configuration is still there on the CMTS. 
This question has been also answered in Med's mail.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Volz (volz)
Sent: Thursday, August 22, 2013 9:12 PM
To: Ralph Droms; Alexandru Petrescu
Cc: [email-masked] WG
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Ralph:

Thanks for bringing up that old draft! There were issues here that caused
this work to be abandoned.

And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I think
one difference in the prefix-pool is that this is more to handle the case
where the relay (router) is told to inject X/48 into the routing instead of
Y/64 or Y/60 that might be going to the client. (This it to avoid having to
inject lots of /64 or /60 routes when many clients are 'connected via the
router'.)

Agentop could have been used to do that, but I'm not sure that was
explicitly discussed or covered (and I didn't check the draft).

I did like agentop better than this proposal in one respect - and that is
its use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrible
idea (IMHO) since there is nothing to guarantee communication on which to
piggyback the request to remove the pool. A lifetime covers that as it
causes the entry to expire on its own. And, 0 lifetimes can be used to
remove 'now'. But that's more of a minor issue as to whether the entire work
is appropriate.

Cable CMTS devices have been snooping address and PD assignments for a long
time now and rather successfully. I suspect that the 'prefix pool' issue
there is handled by static configuration on the CMTS.

- Bernie

-----Original Message-----

- Ralph

---

From: Roberta Maglione <[email-masked]>
Date: Thu, 22 Aug 2013 16:31:26 -0400

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

---

From: <[email-masked]>
Date: Fri, 23 Aug 2013 08:15:07 +0200

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]<mailto:[email-masked]>> wrote:
Re-,

Cheers,
Med

>De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de
>Ralph Droms
>Cc : [email-masked]<mailto:[email-masked]> WG
><[email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi,
>>
>> Le 21/08/2013 14:41, [email-masked]<mailto:[email-masked]> a écrit :
>>> Hi Tomek,
>>>
>>>> -----Message d'origine----- De : [email-masked]<mailto:[email-masked]>
>>>> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Tomek Mrugalski
>>>> dhcwg mailing list [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>
>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 23 Aug 2013 15:52:06 +0800

Roberta - ... I don’t quite get what’s wrong with that?

If operator can't see the advantage of OPTION_PREFIX_POOL, he can still live
with the manual configuration for aggregation route on the PE router. The
draft just propose a new DHCPv6 option, operator could choose  whether or
not to employ it. But I guess you will need route aggregation on most of
your PE router, if you employ DHCPv6-PD for your IPv6 deployment.

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

That sounds the difference between the static (or manual) and the dynamic.
In the network scenario of centralized DHCPv6 server and distributed relay
agent, operator could deploy aggregation route automatic & dynamically on
each relay (or PE router) by the DHCPv6 server while employing
OPTION_PREFIX_POOL, and not by the manual & static configuration on each of
them.

As you know, the server has all the information about the customer's address
plan. If  the DHCPv6 server employs the OPTION_PREFIX_POOL, operator could
also get the additional capability to revise the address plan for customers,
such as renumbering; or adjust the size of prefix pool on the DHCPv6 server
(as the centralized deployment).

Roberta - ... why do you want to add it to customers’ profile in DCHPv6
Server?

As mentioned above, DHCPv6 server not only has information about customer's
profile (eg. the lease & its' status of each customers prefix), but also has
information about the address plan for customers (eg. the associated prefix
pools)). We  could try to define new concept on lease, lifetime or status of
the prefix pool (eg. for the dynamic aggregation route @ PE router), to
enhance the deployment capability of DHCPv6 server.

Best Regards,
Leaf

----------------------------------------------------------------------------
-------------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roberta Maglione
Sent: Friday, August 23, 2013 4:31 AM
To: [email-masked]
Cc: [email-masked] WG; Ralph Droms
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Hello,

Cheers,
Med

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 Aug 2013 11:20:14 +0000

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]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Roberta,

Yes, as indicated in the document, manual configuration is an option… but it has its limits too.

Cheers,
Med

Cc : Ralph Droms; [email-masked]<mailto:[email-masked]> WG

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?

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

Cheers,
Med

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Aug 2013 13:24:36 +0200

> 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) addres…

that isn't handled by netconf, netmod, i2rs already?
not to mention all the other protocols for network management.

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 Aug 2013 11:28:38 +0000

I was joking about the BOF ...

- Bernie (from iPad)

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Aug 2013 13:30:31 +0200

> I was joking about the BOF ...

LOL, I did laugh. ;-)

cheers,
Ole

---

From: <[email-masked]>
Date: Fri, 23 Aug 2013 14:10:55 +0200

Hi Bernie,

This proposal does not conflict with the use of dedicated dynamic provisioning channels (e.g., COPS, NETCONF, home-made scripts, etc.) for other needs. It does focus on a very specific issue of controlling route entries in a specific network element.

The server which owns the information can trigger required route advertisement actions in-band without requiring an out of band mechanism for this purpose. No interface is needed between the dhcp server and a dedicated controller which is responsible for generating and communicating appropriate routing policies to the router.

Cheers,
Med

De : Bernie Volz (volz) [mailto:[email-masked]]
Envoyé : vendredi 23 août 2013 13:20
À : BOUCADAIR Mohamed IMT/OLN
Cc : Roberta Maglione; [email-masked] WG; Ralph Droms
Objet : Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

- Bernie (from iPad)

Cheers,
Med

Hello,

Thanks

Roberta

Cheers,
Med

---

From: [email-masked]
Date: Fri, 23 Aug 2013 14:18:44 +0200 (CEST)

> 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) addres…

As an operator I would prefer DHCPv6 to work similarly to DHCPv4 in a
typical scenario of:

- Large pools are explicitly configured on routers (relay agents).
- DHCP server is allowed to hand out addresses *within these pools*.
- Routers (relay agents) use information in the relayed DHCP packets
to build up some state (for instance making it possible to invalidate
the IP address when the lease expires).

Thus the DHCP server has a *limited* amount of freedom to hand out IP
within pools already known by the routers.

I would be very uncomfortable with, and probably would not want to
use, DHCP options which would let the DHCP server control address
allocation without any kind of preconfiguration on the router.

Steinar Haug, AS 2116

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 23 Aug 2013 20:29:29 +0800

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

Cheers,
Med

Objet : Re: [dhcwg] Anyone interested in continuing
 
Hello,

Cheers,
Med

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 23 Aug 2013 21:16:34 +0800

Steinar - I would be very uncomfortable with, and probably would not want to
use, DHCP options which would let the DHCP server control address allocation
without any kind of preconfiguration on the router.

What kind of preconfiguration on the router you need ? Pls. read my reply to
Bernie's question.

OPTION_PREFIX_POOL defined in this draft just help your relay to know which
pool your customer's prefix are from, and this information could help your
router to do the dynamic route aggregation, which sounds your need on your
PE router.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, August 23, 2013 8:19 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

- Large pools are explicitly configured on routers (relay agents).
- DHCP server is allowed to hand out addresses *within these pools*.
- Routers (relay agents) use information in the relayed DHCP packets to
build up some state (for instance making it possible to invalidate the IP
address when the lease expires).

Thus the DHCP server has a *limited* amount of freedom to hand out IP within
pools already known by the routers.

I would be very uncomfortable with, and probably would not want to use, DHCP
options which would let the DHCP server control address allocation without
any kind of preconfiguration on the router.

Steinar Haug, AS 2116

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Aug 2013 16:48:28 +0200

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

What would be the toc of this DHCPv6 Prefix Delegation and Relay Problem 
Statement?

Alex

> Yes, as indicated in the document, manual configuration is an option. but it
> has its limits too.
>
> Maybe I'm missing something here, but I'm struggling to see the value added
> protocol. Moving to IPv6 you could do the same thing, I don't quite get
> what's wrong with that?
> to customers' profile in DCHPv6 Server?
> Thanks
> Roberta
>

---

From: Roberta Maglione <[email-masked]>
Date: Fri, 23 Aug 2013 14:51:35 -0400

Hi Med, Leaf,

I fully understand the requirement for network automation versus manual
configuration, but I still don’t think defining a new dhcp option is the
right direction to go in order to do routes aggregations in a router.

As somebody else already pointed out here, if you need a way to
automatically interact with the router i2rs is the right place to discuss
your requirements.

In addition you said:

Ø  I confirm this option is not a per-customer configuration parameter.

 If it is not a per-client configuration why  would you like to use DHCP
for that?

I understand that in DHCP Server there are already some global parameters
like the pool of addresses to be used for the clients, but my understanding
of DHCP behavior , and please correct me if I’m wrong, is that the DHCP
Server provides a per-client configuration.

How would it work with this new option? How does the DHCP Server know if it
has to add or not this option if it is not based on client profile or on
client request?

Do you plan to insert the option in all  the DHCP Server replies/to all
clients?

I assume the router is going to install the route once and what does it do
if it gets the same routes more the one? Just ignore? It seems like a waste
of cycles on the router.

In my opinion having global parameters on DHCP Server seems  a major change
in the DHCP model.

Thanks

Roberta

On Fri, Aug 23, 2013 at 2:15 AM, <[email-masked]> wrote:

> Hi Roberta,****
>
> ** **
>
> Yes, as indicated in the document, manual configuration is an option… but
> it has its limits too. ****
>
> ** **
>
> route withdrawals, etc.). ****
>
> ** **
>
> 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. ****
>
> ** **
>
> 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.****
>
> 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?****
>
> to customers’ profile in DCHPv6 Server?****
>
> Thanks****
>
> Roberta****
>
> ** **
>
> On Thu, Aug 22, 2013 at 9:45 AM, <[email-masked]> wrote:****
>
> Re-,
>
> draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior IMHO.****
>
>
> Cheers,
> Med
>
>
> ****
> ****
> https://www.ietf.org/mailman/listinfo/dhcwg****
>
> ** **
>

---

From: "Leaf Yeh" <[email-masked]>
Date: Sun, 25 Aug 2013 23:51:54 +0800

Roberta - I understand that in DHCP Server there are already some global parameters like the pool of addresses to be used for the clients, but my understanding of DHCP behavior , and please correct me if I’m wrong, is that the DHCP Server provides a per-client configuration.

Not sure you have interest to read draft (RAAN, draft-ietf-dhc-dhcpv6-agentopt-delegate) again. 
I believe Bernie (or Tomek) have better answer for this question.

Roberta - How would it work with this new option? How does the DHCP Server know if it has to add or not this option if it is not based on client profile or on client request?

The OPTION_PREFIX_POOL will be included in the Relay-Reply message for DHCPv6-PD Reply to the clients. 
Pls. read the draft (OPTION_PREFIX_POOL) for the details, Madam.

Roberta - Do you plan to insert the option in all  the DHCP Server replies/to all clients? 

Yes, almost every Relay-Reply message for Reply to the clients as described in the draft. 

Roberta - I assume the router is going to install the route once and what does it do if it gets the same routes more the one? Just ignore? 

Read the draft, keep in mind you have a smart PE with strong CPU. :-)

Roberta - It seems like a waste of cycles on the router.

The OPTION_PREFIX_POOL proposed by the draft to include in the Relay-Reply message is not more than 22 bytes with a fixed format. 
Your concern here sounds not a problem.

Roberta - In my opinion having global parameters on DHCP Server seems  a major change in the DHCP model.

The DHCPv6 server already has the ‘global parameters’, such as the prefix pool … as you mentioned above. 
The draft (OPTION_PREFIX_POOL) does intend to enhance the (deployment) capability of DHCPv6 server. Pls. read my last reply mail to you & Med's mail again. 
The solution with a newly defined option is a solution we thought with a minimal protocol change. 
New capability from the new protocol design do need a little change on your habit for the employment in your deployment.

Best Regards,
Leaf

----------------------------------------------------------------------------------------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roberta Maglione
Sent: Saturday, August 24, 2013 2:52 AM
To: [email-masked]
Cc: [email-masked] WG; Ralph Droms
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Hi Med, Leaf,
I fully understand the requirement for network automation versus manual configuration, but I still don’t think defining a new dhcp option is the right direction to go in order to do routes aggregations in a router. 
As somebody else already pointed out here, if you need a way to automatically interact with the router i2rs is the right place to discuss your requirements.
In addition you said:
➢  I confirm this option is not a per-customer configuration parameter.
 If it is not a per-client configuration why  would you like to use DHCP for that?
I understand that in DHCP Server there are already some global parameters like the pool of addresses to be used for the clients, but my understanding of DHCP behavior , and please correct me if I’m wrong, is that the DHCP Server provides a per-client configuration.
How would it work with this new option? How does the DHCP Server know if it has to add or not this option if it is not based on client profile or on client request?
Do you plan to insert the option in all  the DHCP Server replies/to all clients? 
I assume the router is going to install the route once and what does it do if it gets the same routes more the one? Just ignore? It seems like a waste of cycles on the router.
In my opinion having global parameters on DHCP Server seems  a major change in the DHCP model.
Thanks
Roberta

 

 
 
Cheers,
Med

 
Hello,

Cheers,
Med

---

From: Roberta Maglione <[email-masked]>
Date: Sun, 25 Aug 2013 18:04:18 -0400

Hello Leaf,
thanks for your comments please see inline [RM]
Best Regards
Roberta

On Sun, Aug 25, 2013 at 11:51 AM, Leaf Yeh <[email-masked]> wrote:

>
> Not sure you have interest to read draft (RAAN,
> draft-ietf-dhc-dhcpv6-agentopt-delegate) again.
> [RM] The main difference here is that RAAN option was used to provide
> per-client configuration/route while if I understand correctly your
> proposal this option will be used to configure a per-box/per-relay route or
> per-group of users (per-service) route on the relay as both you and Med
> confirmed.

> Roberta - How would it work with this new option? How does the DHCP Server
> know if it has to add or not this option if it is not based on client
> profile or on client request?
>
> [RM]  This is my point: you repeat the same option in every Relay-reply
> message  in order to do a one time/per-relay configuration in my opinion
> this does not seem to be very efficient, but I may be wrong.

> Roberta - I assume the router is going to install the route once and what
> does it do if it gets the same routes more the one? Just ignore?
>
> The OPTION_PREFIX_POOL proposed by the draft to include in the Relay-Reply
> message is not more than 22 bytes with a fixed format.
> [RM] My point was  not about the packet length, but more mode of
> operation: you are asking the Relay to process multiple times the same
> option in order to install a route that is already there.

> The draft (OPTION_PREFIX_POOL) does intend to enhance the (deployment)
> capability of DHCPv6 server. Pls. read my last reply mail to you & Med's
> mail again.
> New capability from the new protocol design do need a little change on
> your habit for the employment in your deployment.
>
>

> How would it work with this new option? How does the DHCP Server know if
> it has to add or not this option if it is not based on client profile or on
> client request?
> it has its limits too.
> same aggregation level as the one proposed in this document.
>
> added by this new option in terms of route aggregation functionality.
> the PE to the DHCPv6 Server; what do you really save here?

---

From: <[email-masked]>
Date: Mon, 26 Aug 2013 08:47:24 +0200

Hi Roberta,

Thank you for your answer.

Please see inline.

Cheers,
Med

Envoyé : vendredi 23 août 2013 20:52

Hi Med, Leaf,

I fully understand the requirement for network automation versus manual configuration, but I still don't think defining a new dhcp option is the right direction to go in order to do routes aggregations in a router.

[Med] Can you please elaborate why this is not a right direction? Isn't prefix assignment a key point which would impact route aggregation? Doesn't prefix assignment has requirements on routing? Couldn't dhcp be tweaked to optimize prefix assignments and avoid increasing the size of routing tables? Wouldn't be there a need to sync prefix assignment state and the routing controller which would interact with a routing engine? Wouldn't be optimize to get rid of that interface and let dhcp pass that information directly to the routing protocol without passing through a routing controller?

[Med] this is not conflicting. I2rs does not define protocols...it does (aim to) define an interface. If we want to use i2rs terminology, this draft proposes to use dhcp as the i2rs interface for the purpose of tweaking route aggregation, and only for this need because this is the place where prefixes are managed.

[Med] The per-client assigned prefix is part of the prefix returned by this option. There is dependency between routing and prefix assignment.

I understand that in DHCP Server there are already some global parameters like the pool of addresses to be used for the clients, but my understanding of DHCP behavior , and please correct me if I'm wrong, is that the DHCP Server provides a per-client configuration.

[Med] The current text says it is inserted in all messages by relay. The server may not inserted the option in all responses. It can insert the option only if there are changes.

[Med] The server is not requirement to insert the option in all responses. BTW, in any dynamic provisioning protocol there is a provisioning epoch to be followed to ensure consistent policies are enforced. Inserting the option on all relay-agent messages is a way to preserve a provisioning epoch.

[Med] There is no change in the model. The prefix returned in the option may be for instance a per-region prefix. See the example in: http://tools.ietf.org/html/draft-lemon-dhc-topo-conf-01#section-4:

   "... In this example, link C is a regional backbone for an ISP.  Link E is
   also a regional backbone for that ISP.  Relays A, B, C and D are PE
   routers, and Links A, B, F and G are actually link aggregators with
   individual layer 2 circuits to each customer-\u002Dfor example, the
   relays might be DSLAMs or cable head-end systems.  At each customer
   site we assume there is a single CPE device attached to the link. ..."

draft-ietf-dhc-dhcpv6-prefix-pool-opt does only return the aggregate for each relays A, B, C and D. As you can see draft-lemon-*, this information (i.e., /40s) is configured to the server.

Thanks

Roberta

On Fri, Aug 23, 2013 at 2:15 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roberta,

Cheers,
Med

De : Roberta Maglione [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : jeudi 22 août 2013 22:31
À : BOUCADAIR Mohamed IMT/OLN
Cc : Ralph Droms; [email-masked]<mailto:[email-masked]> WG

Hello,

Thanks

Roberta

Cheers,
Med

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 26 Aug 2013 22:35:57 +0800

[RM] The main difference here is that RAAN option was used to provide per-client configuration/route while if I understand correctly your proposal this option will be used to configure a per-box/per-relay route or per-group of users (per-service) route on the relay as both you and Med confirmed. 

The better understanding is that OPTION_PREFIX_POOL is used for a group of 'clients', whose client's PD prefixes is from the same pool. The OPTION_PREFIX_POOL is associated with those OPTION_IA_PDs for the clients. The DHCPv6 server has full knowledge (including lease) about this kind of resource in your address plan.

[RM]  This is my point: you repeat the same option in every Relay-reply message  in order to do a one time/per-relay configuration in my opinion this does not seem to be very efficient, but I may be wrong.

In the mechanism described in this draft, the relay includes OPTION_ORO in the Relay-Forward message to request the server to response OPTION_PREFIX_POOL included in the Relay-Reply message. The relay don't know whether the prefix will be delegated to the client is from a new prefix pool, it will include OPTION_ORO in the Relay-Forward of Solicit/Request message to request the server to response OPTION_PREFIX_POOL. After T1/T2 of this client, the relay who keep status of each lease of the client's PD prefixes in the same pool might know the 'Lease of the Pool' has not expired; but it doesn't know whether the server had changed the status of the pool according to policy on the route aggregation or not, it still will include OPTION_ORO in the Relay-Forward of Renew/Rebind message to request the server to response OPTION_PREFIX_POOL.

[RM] My point was  not about the packet length, but more mode of operation: you are asking the Relay to process multiple times the same option in order to install a route that is already there.   

The draft has not touched how to implement the aggregated route (eg. black-hole route) into the routing table yet, but to provide the PE router the information about the prefix pools and their status, then to sync the status of pools on the server with the status of pools on the relay through the above 'piggyback' option in the PD messages. The draft believe your PE router will have enough logic to keep (or handle) each lease of the client's PD prefix and the status of the associated aggregated routes (or the prefix pools). That means that your PE router might need to establish a new table to keep the status of the associated prefix pools (or the aggregated routes); only after the status of the prefix pools changed, then your PE router need to take action to add or withdraw the associated route.

Best Regards,
Leaf

---------------------------------------------------------------------------------
From: Roberta Maglione [mailto:[email-masked]] 
Sent: Monday, August 26, 2013 6:04 AM
To: Leaf Yeh
Cc: [email-masked]; [email-masked] WG; Ralph Droms
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Hello Leaf,

[RM] The main difference here is that RAAN option was used to provide per-client configuration/route while if I understand correctly your proposal this option will be used to configure a per-box/per-relay route or per-group of users (per-service) route on the relay as both you and Med confirmed. 

[RM]  This is my point: you repeat the same option in every Relay-reply message  in order to do a one time/per-relay configuration in my opinion this does not seem to be very efficient, but I may be wrong. 

[RM] My point was  not about the packet length, but more mode of operation: you are asking the Relay to process multiple times the same option in order to install a route that is already there.   

Best Regards,
Leaf

Hi Med, Leaf,

Cheers,
Med

Hello,

Cheers,
Med

---

From: Ralph Droms <[email-masked]>
Date: Mon, 26 Aug 2013 10:29:34 -0700

Bernie - thanks for the clarifications.

I'm curious about the demand for this option.  Is there explicit demand from a group of SPs that want to use this option, or is being defined in speculation of SP demand?  Is it really the case that the SP may dynamically change the prefix delegation architecture in a dynamic way that requires this specific automated configuration?

In my opinion, piggy-backing the prefix-pool option on client-server communication is not appropriate.  As you point out, piggy-backing may not provide relay-router/server communication at the time it is needed.  Also, if I read the draft correctly and the relay-router snoops the server->client message to determine how to interpret the prefix-pool-opt, I think it would be much cleaner to include the operation code in the prefix-pool-opt itself.  If I recall correctly from the discussion of agentopt-delegate, there were questions about the reliability of piggy-backing: suppose messages are delivered out-of-order or delivered through different relay agents?

Someone else pointed out that there are many other configuration knobs that need to be set in the relay-router.  Why use DHCP just for the prefix routing and not the other configuration?

Has the alternative of a routing protocol been considered?

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 26 Aug 2013 18:08:44 +0000

Hi Ralph:

This draft is a WG document (was adopted September 2012) and there has been a WGLC that did not pass (not enough interest last April) - and in Berlin there was no interest when Tomek asked the WG. Tomek sent out the email to gauge the level of interest as the WG meeting is a barometer, but it should also go to the list. I haven't reviewed the detailed responses, but I don't think there has been strong support (and I think an equal level of opposition).

Tomek will review September 2nd (I will be on vacation) and announce results to the list.

If there is explicit demand from a group of SPs, hopefully they will let it be known (and perhaps provide strong motivation as to why this should be via DHCP rather than alternatives).

I too (as an individual, with co-chair hat off) am skeptical of the value of this work.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Monday, August 26, 2013 1:30 PM
To: Bernie Volz (volz)
Cc: [email-masked] WG; Alexandru Petrescu
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

- Ralph

On Aug 22, 2013, at 6:12 AM 8/22/13, Bernie Volz (volz) <[email-masked]> wrote:

> And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I 
> think one difference in the prefix-pool is that this is more to handle 
> the case where the relay (router) is told to inject X/48 into the 
> routing instead of Y/64 or Y/60 that might be going to the client. 
> (This it to avoid having to inject lots of /64 or /60 routes when many 
> clients are 'connected via the router'.)
> 
>>>> Envoyé

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 27 Aug 2013 11:54:06 +0800

[Ralph] I think it would be much cleaner to include the operation code in
the prefix-pool-opt itself.  

The operation code in the OPTION_PREFIX_POOL defined in this draft sounds in
the 'status' field.

[Ralph] If I recall correctly from the discussion of agentopt-delegate,
there were questions about the reliability of piggy-backing: suppose
messages are delivered out-of-order or delivered through different relay
agents?

I guess the reliability of the DHCPv6 option (eg. OPTION_ORO,
OPTION_PREFIX_POOL) sounds the same as that of DHCPv6 (PD) message

[Ralph] Someone else pointed out that there are many other configuration
knobs that need to be set in the relay-router. Why use DHCP just for the
prefix routing and not the other configuration?

Just because this part could be dynamic.

Best Regards,
Leaf

-----Original Message-----
Sent: Tuesday, August 27, 2013 1:30 AM

I'm curious about the demand for this option.  Is there explicit demand from
a group of SPs that want to use this option, or is being defined in
speculation of SP demand?  Is it really the case that the SP may dynamically
change the prefix delegation architecture in a dynamic way that requires
this specific automated configuration?

In my opinion, piggy-backing the prefix-pool option on client-server
communication is not appropriate.  As you point out, piggy-backing may not
provide relay-router/server communication at the time it is needed.  Also,
if I read the draft correctly and the relay-router snoops the server->client
message to determine how to interpret the prefix-pool-opt, I think it would
be much cleaner to include the operation code in the prefix-pool-opt itself.
If I recall correctly from the discussion of agentopt-delegate, there were
questions about the reliability of piggy-backing: suppose messages are
delivered out-of-order or delivered through different relay agents?

Someone else pointed out that there are many other configuration knobs that
need to be set in the relay-router.  Why use DHCP just for the prefix
routing and not the other configuration?

- Ralph

> 
> Cable CMTS devices have been snooping address and PD assignments for a

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 29 Aug 2013 17:52:29 +0800

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?

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

Alex

> ------
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Bernie Volz (volz)
> 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?
> Yes, as indicated in the document, manual configuration is an option. 
> but it has its limits too.
>
> 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.
>
> 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 
> Maybe I'm missing something here, but I'm struggling to see the value 
> 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?
> 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
>
> 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.
>> 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?
>>
>>
>> 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
>>>
>>>> because the DHCP server has the knowledge of the prefix 
>>>> assignments; and therefore routes can be triggered with dhcpv6 .
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Aug 2013 12:14:14 +0200

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
>
>
>
> [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
> Le 23/08/2013 14:29, Leaf Yeh a écrit : [...]
> 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
>> 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
>> <[email-masked]> wrote: Hi Roberta,
>>
>> Yes, as indicated in the document, manual configuration is an
>> option. but it has its limits too.
>>
>> 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.
>>
>> 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.
>>
>> 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"
>>> [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?
>>>
>>>
>>>> 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
>>>>
>>>>> 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
>>>>> 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
>>>>>
>>>>>> [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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> _______________________________________________ dhcwg
>>>>>> mailing list [email-masked]
>>>>> _______________________________________________ dhcwg mailing
>>>>> list [email-masked]
>>>> _______________________________________________ dhcwg mailing
>>>> list [email-masked]
>>> _______________________________________________ dhcwg mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg