Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

From: Ole Trøan <[email-masked]>
Date: Mon, 3 Sep 2012 10:03:38 +0200

> The authors have proposed that the working group adopt the prefix pool option draft as a working group item.   We have engaged in some correspondence with participants in the Routing Area, and while some helpful advice was given, no objections were raised to going forward with the work, and it's a DHCP protocol extension, so it makes sense for it to happen in the DHC working group.
> 
> The document proposes an extension to the DHCP protocol that allows the DHCP server to communicate prefixes to the provider edge router when doing prefix delegation, such that this router can advertise a route to an aggregate prefix, rather than to many individual prefixes, and so that this router does not have to perform ad-hoc prefix aggregation, which may produce less optimal results.
> 
> If you think this work should be adopted by the working group, please reply to this message saying so.   If you think this work should not be adopted by the working group, please reply to this message saying so.   We will evaluate consensus on September 7.

I'm generally uncomfortable with piggybacking on the client initiated protocol, to manage a DHCPv6 relay sitting in the middle of the conversation.

I do not think it is a good idea to require DHCPv6 relays to rewrite DHCPv6 client messages. does this work with DHCPv6 authentication?

do we want to make DHCP a general management protocol of the DR/first-hop router?

I am against adopting this document as a working group document.

cheers,
Ole

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 03 Sep 2012 16:48:48 +0200

On 03.09.2012 10:03, Ole Trøan wrote:
>> [...] 
>> If you think this work should be adopted by the working
>> group, please reply to this message saying so.   If you think this
>> work should not be adopted by the working group, please reply to
>> this message saying so.   We will evaluate consensus on September
>> 7.
> 
> I'm generally uncomfortable with piggybacking on the client
> initiated protocol, to manage a DHCPv6 relay sitting in the middle of
> the conversation.
Piggybacking is not very elegant, but the alternatives are worse. If you
chose not to piggyback, you would have to use some form (something like)
leasequery + active pushback from the server to notify relays that
something has changed. Such a protocol would add new message types, new
connections, perhaps even new state in the server. What is such
hypothetical prefix-pool-queries came from outside your network (or any
unathorized source)? So new attack vectors would have to be considered
and possible protected against.

With prefix pool option in RELAY_REPL that contains PD REPLY, your
server already decided that is ok to respond. No extra connections, no
extra message types, no new state. So in my opinion piggybacking is not
the most elegant solution, but the alternatives are much worse.

One thing that should probably improved is handing of the case when
server policy changes. Right now the draft says to trigger reconfigure
and force a client to start reconfigure process. The client won't get
any new or changed configuration. Also, there may be a network does not
have any client that supports reconfigure (which is optional). So in my
opinion that part of the draft requires some extra work. Does it mean
that we should throw away the whole concept? In my opinion - definitely not.

> I do not think it is a good idea to require DHCPv6 relays to rewrite 
> DHCPv6 client messages.
Nobody suggested such a thing. Relays would consume some options put in
RELAY-REPL. The decapsulation process would work as it is now - take
contents of RELAY-MSG option and send it downlink (be it the next relay
or the client - it doesn't matter).

> does this work with DHCPv6 authentication?
It doesn't affect it at all. Servers that auhenticate their responses
are signing REPLY message that is in turn encapsulated in RELAY-REPL.
THe prefix-pool option is insterted in RELAY-REPL and the REPLY inside
is never modified. prefix-pool never reaches the client. If that is was
your impression after reading the draft, perhaps it should be clarified
in the text?

Tomek

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Tue, 4 Sep 2012 10:45:46 +0530

Tomek,

Since the goal of the solution is to transfer a prefix table from dhcp server to the relay why not use DHCP inform with options,or a separate message to get this information(draft-joshi-dhc-dhcpv6-aggr-route-opt)  ? 

This would not have the overhead per transaction and also the handling at the relay would be much elegant and simpler.
Current draft requires relay to implement bulk lease query and additional processing per relayed PD request.

As such the prefix routes are not supposed to change frequently and would in any case require additional routing policy and routing protocol configuration which would be done external to DHCP.

So is this additional complexity & piggy backing at relay per dhcp PD exchange really required or should alternatives be considered /

--
Shree

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Tomek Mrugalski
>Sent: Monday, September 03, 2012 8:19 PM
>To: [email-masked]
>Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 4 Sep 2012 06:44:52 +0000

Support.

> Ted Lemon
> Sent: Friday, August 24, 2012 11:32 PM
> To: [email-masked] WG
> Subject: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
> 
> The authors have proposed that the working group adopt the prefix pool option
> draft as a working group item.   We have engaged in some correspondence
> with participants in the Routing Area, and while some helpful advice was given,
> no objections were raised to going forward with the work, and it's a DHCP
> protocol extension, so it makes sense for it to happen in the DHC working
> group.
> 
> The document proposes an extension to the DHCP protocol that allows the
> DHCP server to communicate prefixes to the provider edge router when doing
> prefix delegation, such that this router can advertise a route to an aggregate
> prefix, rather than to many individual prefixes, and so that this router does not
> have to perform ad-hoc prefix aggregation, which may produce less optimal
> results.
> 
> If you think this work should be adopted by the working group, please reply to
> this message saying so.   If you think this work should not be adopted by the
> working group, please reply to this message saying so.   We will evaluate
> consensus on September 7.
>

---

From: Ole Trøan <[email-masked]>
Date: Tue, 4 Sep 2012 11:29:03 +0200

Tomek,

> the most elegant solution, but the alternatives are much worse.

this doesn't mean a separate binding for the relay set of options?

the alternatives as I see it are:
 - use whatever other management / configuration protocol used to manage the relay
 - use a separate DHC session for the relay. noting that DHC isn't the protocol
   normally used to manage PE routers.

there are lots of other hammers in the toolbox, so we don't need to use the DHC hammer for every problem we have...

> that we should throw away the whole concept? In my opinion - definitely not.

right, I think that is broken.

> your impression after reading the draft, perhaps it should be clarified

ah, I see. I must have missed that in the text. I see there is a MAY in 3315.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Sep 2012 13:56:26 +0000

On Sep 4, 2012, at 1:15 AM, "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]<mailto:[email-masked]>> wrote:
This would not have the overhead per transaction and also the handling at the relay would be much elegant and simpler.
Current draft requires relay to implement bulk lease query and additional processing per relayed PD request.

The overhead per transaction here is a bit of a red herring—we're talking about thirteen bytes, if I count correctly.

Furthermore, the working group already went down the path of separating out the transactions a couple of years ago, and determined that there were synchronization problems; that work was eventually dropped for lack of interest.

The problem remains unsolved; this is actually a pretty good solution, because it involves fate sharing, with a netconf solution wouldn't have, and uses an established communications path, which netconf/yang doesn't offer.

This is definitely better than the solution vendors are currently offering, which is to simply sniff the prefixes from DHCP messages to the client.   With my working group chair hat off, I'm in favor of doing this work precisely because it solves the problem neatly, and no better solution has ever been presented of which I'm aware.

---

From: Ole Trøan <[email-masked]>
Date: Tue, 4 Sep 2012 18:32:21 +0200

Ted,

> The problem remains unsolved; this is actually a pretty good solution, because it involves fate sharing, with a netconf solution wouldn't have, and uses an established communications path, which ne…

fate sharing of what? the client functions independently of whatever aggregate route there is for a whole block of subscribers. this just adds another cog in the machinery that may fail.

> This is definitely better than the solution vendors are currently offering, which is to simply sniff the prefixes from DHCP messages to the client.   With my working group chair hat off, I'm in fav…

this does not solve the DHCPv6 PD problem of route injection. a route needs to be installed per client, and snooping is still needed for that. this proposal _only_ solves the problem of installing an aggregate route for multiple PD RRs into a PE/relay. this is most typically done with static configuration today.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Sep 2012 17:43:47 +0000

> fate sharing of what? the client functions independently of whatever aggregate route there is for a whole block of subscribers. this just adds another cog in the machinery that may fail.

Fate sharing in the sense that the DHCP server is best able to know from what aggregate prefix prefixes for clients on a particular router will be allocated, and the DHCP packet is the way these prefixes get allocated to the client.   So we can be sure that if the network is working at all, it will be working completely.

> this does not solve the DHCPv6 PD problem of route injection. a route needs to be installed per client, and snooping is still needed for that. this proposal _only_ solves the problem of installing…

It solves half the problem: configuring the route that the router advertises.   You are correct that it doesn't solve the other half—figuring out where to send packets downstream.   But actually, snooping the DHCP packet is a perfectly good solution for this problem; what is lacking is a standard that says how it's done. 

What snooping is _not_ good for is figuring out what route to advertise upstream.   To say that the upstream route is currently done with static configuration is synonymous with saying that the problem is currently unsolved.

---

From: Ole Trøan <[email-masked]>
Date: Tue, 4 Sep 2012 20:02:55 +0200

> Fate sharing in the sense that the DHCP server is best able to know from what aggregate prefix prefixes for clients on a particular router will be allocated, and the DHCP packet is the way these pr…

I look at it differently. you are adding more complexity on functions that are not in the data path. in my book that isn't fate sharing.

> It solves half the problem: configuring the route that the router advertises.   You are correct that it doesn't solve the other half—figuring out where to send packets downstream.   But actually, s…

we did try with the use of the RAAN option.

> What snooping is _not_ good for is figuring out what route to advertise upstream.   To say that the upstream route is currently done with static configuration is synonymous with saying that the pro…

this is like saying that configuring OSPF on a router is a unsolved problem, just because it isn't done with DHCP. ;-)

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Sep 2012 19:32:57 +0000

> I look at it differently. you are adding more complexity on functions that are not in the data path. in my book that isn't fate sharing.

How is this not on the data path?

> we did try with the use of the RAAN option.

Right, but this wasn't useful because it added no functionality—the only purpose it served was to avoid having the relay agent look in the client part of the DHCP packet.   I never understood why you guys wanted this.   If you think the work is important, I am certainly not opposed to reviving it, though—it was a perfectly good draft.

> this is like saying that configuring OSPF on a router is a unsolved problem, just because it isn't done with DHCP. ;-)

No, if OSPF is how these routers are being configured, that's not what I think of as static configuration.   Is that in fact the case?   It's my understanding that there is no clean dynamic configuration mechanism that ties back to the address allocation system (that is, to DHCP). 

It seems to me that what we are talking about here is exactly analogous to what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of which seem to be good solutions that are widely deployed and work well for network providers.   If there's a better way, I'm all ears, but when I asked in the routing area, I got some pretty vague answers that sounded a lot like "it's configured statically."

---

From: Ralph Droms <[email-masked]>
Date: Tue, 4 Sep 2012 16:12:24 -0400

> It seems to me that what we are talking about here is exactly analogous to what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of which seem to be good solutions that are widely…

One issue that comes to mind for me is that the DHCPv6 server may not, in fact, have complete information about the routing and prefix aggregation information.  The DHCPv6 server would be inferring aggregation information from the pools of prefixes it has to delegate.  Looked at another way, there is likely an oracle of network configuration somewhere from which the delegated prefix pools and prefix aggregation for routing is derived.  The DHCPv6 server might be able to make an educated guess but it doesn't have necessarily authoritative information.

Another issue with piggybacking is that the routing information may change independent of any specific DHCPv6 message exchanges (someone else raised this issue), so that there would be noway to send updates if there was no DHCPv6 traffic to send through the router.

Why would this aggregation information not be provided through whatever configuration mechanism is used to manage the router?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Sep 2012 20:23:18 +0000

On Sep 4, 2012, at 4:12 PM, Ralph Droms <[email-masked]<mailto:[email-masked]>>
 wrote:
One issue that comes to mind for me is that the DHCPv6 server may not, in fact, have complete information about the routing and prefix aggregation information.  The DHCPv6 server would be inferring aggregation information from the pools of prefixes it has to delegate.  Looked at another way, there is likely an oracle of network configuration somewhere from which the delegated prefix pools and prefix aggregation for routing is derived.  The DHCPv6 server might be able to make an educated guess but it doesn't have necessarily authoritative information.

I don't think you'd want to configure this option if you didn't think the DHCP server had accurate information about the network configuration.

Can you describe an actual use case where this would happen?   It seems to me that in a situation like the one you describe, you'd have chaos and wreckage, because all the CPE devices would still be configured with prefixes that were no longer valid.

Because it might change dynamically whereas the rest of the router configuration is static?

---

From: Leaf yeh <[email-masked]>
Date: Wed, 5 Sep 2012 03:16:51 +0000

Ralph - One issue that comes to mind for me is that the DHCPv6 server may not, in fact, have complete information about the routing and prefix aggregation information.  The DHCPv6 server would be inferring aggregation information from the pools of prefixes it has to delegate.  Looked at another way, there is likely an oracle of network configuration somewhere from which the delegated prefix pools and prefix aggregation for routing is derived.  The DHCPv6 server might be able to make an educated guess but it doesn't have necessarily authoritative information.

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  If we are only thinking about the delegated prefix to customer and its pre-configured prefix pool on the DHCPv6 server (or DR), the server does know all the lease of the delegated prefix, then can definitely derive the status ('Active' or 'Released') of the prefix pool. There is no 'educated guess' here. Because the server acts as the manager (or administrator) of all the pools, he authorize (or delegate) the prefix to the customer, and know all the information (or aspects) of the delegated prefixes.

Ralph - Another issue with piggybacking is that the routing information may change independent of any specific DHCPv6 message exchanges (someone else raised this issue), so that there would be no way to send updates if there was no DHCPv6 traffic to send through the router.

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The draft creates somewhat of new reasonable function on the server to support the policy change (for route aggregation based on the information of the prefix pools), the basic proposal in the draft is to utilize the process of 'Prefix Delegation Reconfiguration' to trigger the immediately update. See Section 6 of the draft.

Ralph - Why would this aggregation information not be provided through whatever configuration mechanism is used to manage the router?

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  DHCPv6-PD works closely with the prefix pools, (which always mean the necessary aggregation route in Ole's static configuration,) it could be the simplest way to do the dynamic parameter provisioning to PE router.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Wednesday, September 05, 2012 4:12 AM
To: Lemon Ted; Ole Trøan
Cc: [email-masked] WG
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

On Sep 4, 2012, at 3:32 PM 9/4/12, Ted Lemon wrote:

> Right, but this wasn't useful because it added no functionality-the only purpose it served was to avoid having the relay agent look in the client part of the DHCP packet.   I never understood why you guys wanted this.   If you think the work is important, I am certainly not opposed to reviving it, though-it was a perfectly good draft.
> 

- Ralph

---

From: [email-masked]
Date: Wed, 5 Sep 2012 11:35:53 +0800

But the prefix pool transfer between DHCP server and DHCP Relay also needs 
to be authenticated.

---

From: Leaf yeh <[email-masked]>
Date: Wed, 5 Sep 2012 04:14:59 +0000

Ole - we did try with the use of the RAAN option.

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The draft adopts roughly the same design idea as that of OPTION_RAAN, no new DHCPv6 message here.

Ole - this is like saying that configuring OSPF on a router is a unsolved problem, just because it isn't done with DHCP. ;-)

The explanation from Ted about the routing aspect is thorough. We all know discussion on OSPF is not in the scope of this draft.

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The draft proposed the PE router to add (or withdraw) one more route (called as the aggregation route) per OPTION_PREFIX_POOL. The routing protocol (such as OSFP, ISIS) enabled on the network-facing interface of the PE router helps to advertise this additional route to the ISP core network.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Tr?an
Sent: Wednesday, September 05, 2012 2:03 AM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

> It solves half the problem: configuring the route that the router advertises.   You are correct that it doesn't solve the other half-figuring out where to send packets downstream.   But actually, snooping the DHCP packet is a perfectly good solution for this problem; what is lacking is a standard that says how it's done. 

cheers,
Ole

---

From: <[email-masked]>
Date: Wed, 5 Sep 2012 07:42:29 +0200

Dear Chairs, all,

I support the adoption of this draft as it allows to:

* Avoid misbehaving routers which inject a large number of individual prefixes instead of aggregating them. The behaviour of the edge router supporting this mechanism is deterministic and it does not depend on a specific implementation. Network operators may decide to inject an aggregate even if all individual prefixes are not assigned to connected nodes. 

* Control the prefixes to be injected in routing without requiring a dedicated configuration interface no a new DHCP message. 

* Retrieve the set of routes injected by the router embedding the relay agent.

Cheers,
Med

PS: I'm also co-author of the draft.

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Ted Lemon
>Envoyé : vendredi 24 août 2012 17:32
>À : [email-masked] WG
>Objet : [dhcwg] Call for Adoption: 
>draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
>
>The authors have proposed that the working group adopt the 
>prefix pool option draft as a working group item.   We have 
>engaged in some correspondence with participants in the 
>Routing Area, and while some helpful advice was given, no 
>objections were raised to going forward with the work, and 
>it's a DHCP protocol extension, so it makes sense for it to 
>happen in the DHC working group.
>
>The document proposes an extension to the DHCP protocol that 
>allows the DHCP server to communicate prefixes to the provider 
>edge router when doing prefix delegation, such that this 
>router can advertise a route to an aggregate prefix, rather 
>than to many individual prefixes, and so that this router does 
>not have to perform ad-hoc prefix aggregation, which may 
>produce less optimal results.
>
>If you think this work should be adopted by the working group, 
>please reply to this message saying so.   If you think this 
>work should not be adopted by the working group, please reply 
>to this message saying so.   We will evaluate consensus on September 7.
>

---

From: Ole Trøan <[email-masked]>
Date: Wed, 5 Sep 2012 10:06:42 +0200

Ted,

> How is this not on the data path?

the DHCP server is not on the data path. unless one follows the model described in 3633 where the DHCP server is on the PE router.

[...]

> No, if OSPF is how these routers are being configured, that's not what I think of as static configuration.   Is that in fact the case?   It's my understanding that there is no clean dynamic configu…

I might be missing something here. I don't understand how the aggregate route for a set of delegated prefixes is dynamic. when and how could all subscribers within a aggregate move?

> It seems to me that what we are talking about here is exactly analogous to what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of which seem to be good solutions that are widely…

hmm, I didn't think the IPv4 aggregate route was deduced or configured from DHCPv4 either. the deployments I'm aware of, the PE is always configured outside of DHCP with the IPv4 subnets / aggregate routes. what's the analogy?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Sep 2012 13:16:37 +0000

> the DHCP server is not on the data path. unless one follows the model described in 3633 where the DHCP server is on the PE router.

Oh, I see what you mean.   No, the DHCP server isn't on the data path, but it's using the data path.   The fate sharing is with respect to the PE router—the relay—and the CPE router.   Since both are being configured by the same message, there is no possibility of partial configuration.

> I might be missing something here. I don't understand how the aggregate route for a set of delegated prefixes is dynamic. when and how could all subscribers within a aggregate move?

The prefix might expand or contract depending on usage patterns.   I don't know if that's actually a use case that Leaf is considering—it's just one that occurred to me when I read the draft.

> hmm, I didn't think the IPv4 aggregate route was deduced or configured from DHCPv4 either. the deployments I'm aware of, the PE is always configured outside of DHCP with the IPv4 subnets / aggregat…

The analogy is that the PE router's downstream routing configuration is in fact determined from snooping DHCPv4.  This is the entire justification for leasequery—to rebuild the router's DHCP snooping cache after a power cycle.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 6 Sep 2012 03:00:32 +0000

Ole - I might be missing something here. I don't understand how the aggregate route for a set of delegated prefixes is dynamic. when and how could all subscribers within a aggregate move?

It is my duty to make you love it. :-)

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The draft defined the 'Status' of the PD prefix pool in Section 4, which maintained on the server (and the relay). It has 2 codes now, 'Active' or 'Released', which can be derived from the leases of delegated subscriber prefixes, or be set by the administration of server. The 'Status' in the OPTION_PREFIX_POOL received by the relay is used for the addition or removal the aggregation route on the PE router (acting as the relay).

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Tr?an
Sent: Wednesday, September 05, 2012 4:07 PM
To: Ted Lemon
Cc: [email-masked] WG
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Ted,

[...]

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2012 14:10:43 +0200

Le 04/09/2012 18:32, Ole Trøan a écrit :
> Ted,
>
>>> This would not have the overhead per transaction and also the
>>> handling at the relay would be much elegant and simpler. Current
>>> draft requires relay to implement bulk lease query and
>>> additional processing per relayed PD request.
>>
>> The overhead per transaction here is a bit of a red herring—we're
>> talking about thirteen bytes, if I count correctly.
>>
>> Furthermore, the working group already went down the path of
>> separating out the transactions a couple of years ago, and
>> determined that there were synchronization problems; that work was
>> eventually dropped for lack of interest.
>>
>> The problem remains unsolved; this is actually a pretty good
>> solution, because it involves fate sharing, with a netconf
>> solution wouldn't have, and uses an established communications
>> path, which netconf/yang doesn't offer.
>
> fate sharing of what? the client functions independently of whatever
> aggregate route there is for a whole block of subscribers. this just
> adds another cog in the machinery that may fail.
>
>> This is definitely better than the solution vendors are currently
>> offering, which is to simply sniff the prefixes from DHCP messages
>> to the client.   With my working group chair hat off, I'm in favor
>> of doing this work precisely because it solves the problem neatly,
>> and no better solution has ever been presented of which I'm aware.
>
> this does not solve the DHCPv6 PD problem of route injection. a
> route needs to be installed per client, and snooping is still needed
> for that. this proposal _only_ solves the problem of installing an
> aggregate route for multiple PD RRs into a PE/relay.

In a sense I agree - this proposal seems to still require snooping.
(i.e. existing single prefixes in PD require snooping and pool-opt draft
requires it too).

> this is most typically done with static configuration today.

Well no, static configuration at Relay is not sufficient for PD to work,
even if we dont talk pool-opt draft - there is a need of that route at
Relay.  There is no other solution to that than DHCP Relay to become
more intelligent (i.e. "snoop").

Alex

>
> cheers, Ole
>
>
>
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2012 14:12:22 +0200

Le 04/09/2012 20:02, Ole Trøan a écrit :
>>> fate sharing of what? the client functions independently of
>>> whatever aggregate route there is for a whole block of
>>> subscribers. this just adds another cog in the machinery that may
>>> fail.
>>
>> Fate sharing in the sense that the DHCP server is best able to know
>> from what aggregate prefix prefixes for clients on a particular
>> router will be allocated, and the DHCP packet is the way these
>> prefixes get allocated to the client.   So we can be sure that if
>> the network is working at all, it will be working completely.
>
> I look at it differently. you are adding more complexity on functions
> that are not in the data path. in my book that isn't fate sharing.
>
>>> route needs to be installed per client, and snooping is still
>>> needed for that. this proposal _only_ solves the problem of
>>> installing an aggregate route for multiple PD RRs into a
>>> PE/relay. this is most typically done with static configuration
>>> today.
>>
>> It solves half the problem: configuring the route that the router
>> advertises.   You are correct that it doesn't solve the other
>> half—figuring out where to send packets downstream.   But actually,
>> snooping the DHCP packet is a perfectly good solution for this
>> problem; what is lacking is a standard that says how it's done.
>
>> What snooping is _not_ good for is figuring out what route to
>> advertise upstream.   To say that the upstream route is currently
>> done with static configuration is synonymous with saying that the
>> problem is currently unsolved.
>
> this is like saying that configuring OSPF on a router is a unsolved
> problem, just because it isn't done with DHCP. ;-)

But for this there is a need to have OSPF talk DHCP or vice-versa.  Is 
there a spec for DHCP-OSPF Gateway?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2012 14:23:32 +0200

Le 05/09/2012 05:16, Leaf yeh a écrit :
> Ralph - One issue that comes to mind for me is that the DHCPv6 server
> may not, in fact, have complete information about the routing and
> prefix aggregation information.

I tend to agree with this statement.

> The DHCPv6 server would be inferring aggregation information from
> the pools of prefixes it has to delegate.  Looked at another way,
> there is likely an oracle of network configuration somewhere from
> which the delegated prefix pools and prefix aggregation for routing
> is derived. The DHCPv6 server might be able to make an educated guess
> but it doesn't have necessarily authoritative information.

I wonder about the implementation of educated guess...

Given a set of prefixes find their common longest prefix (easy) and make
sure its other subprefixes are not in use elsewhere (more difficult.)

I mean I dont think an educated guess could be done reasonably to form a
common prefix and instruct the Relay about it.  Even less that Relay to
advertise the aggregated prefix instead of numerous specific routes.

But I agree there may be a problem in too numerous specific routes
advertised by Relay to routers, about the dynamically delegated prefixes.

Alex

>
>
> General Idea Clarification on the draft (OPTION_PREFIX_POOL):  If we
>  are only thinking about the delegated prefix to customer and its
> pre-configured prefix pool on the DHCPv6 server (or DR), the server
> does know all the lease of the delegated prefix, then can definitely
>  derive the status ('Active' or 'Released') of the prefix pool. There
>  is no 'educated guess' here. Because the server acts as the manager
>  (or administrator) of all the pools, he authorize (or delegate) the
>  prefix to the customer, and know all the information (or aspects) of
>  the delegated prefixes.
>
>
> Ralph - Another issue with piggybacking is that the routing
> information may change independent of any specific DHCPv6 message
> exchanges (someone else raised this issue), so that there would be no
> way to send updates if there was no DHCPv6 traffic to send through
> the router.
>
>
> General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The
> draft creates somewhat of new reasonable function on the server to
> support the policy change (for route aggregation based on the
> information of the prefix pools), the basic proposal in the draft is
>  to utilize the process of 'Prefix Delegation Reconfiguration' to
> trigger the immediately update. See Section 6 of the draft.
>
>
> Ralph - Why would this aggregation information not be provided
> through whatever configuration mechanism is used to manage the
> router?
>
>
> General Idea Clarification on the draft (OPTION_PREFIX_POOL):
> DHCPv6-PD works closely with the prefix pools, (which always mean the
> necessary aggregation route in Ole's static configuration,) it could
> be the simplest way to do the dynamic parameter provisioning to PE
> router.
>
>
>
> Best Regards, Leaf
>
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ralph Droms Sent:
> Wednesday, September 05, 2012 4:12 AM To: Lemon Ted; Ole Trøan Cc:
> [email-masked] WG Subject: Re: [dhcwg] Call for Adoption:
>>> I look at it differently. you are adding more complexity on
>>> functions that are not in the data path. in my book that isn't
>>> fate sharing.
>>
>> Right, but this wasn't useful because it added no functionality-the
>> only purpose it served was to avoid having the relay agent look in
>> the client part of the DHCP packet.   I never understood why you
>> guys wanted this.   If you think the work is important, I am
>> certainly not opposed to reviving it, though-it was a perfectly
>> good draft.
>>
>>> this is like saying that configuring OSPF on a router is a
>>> unsolved problem, just because it isn't done with DHCP. ;-)
>>
>> No, if OSPF is how these routers are being configured, that's not
>> what I think of as static configuration.   Is that in fact the
>> case?   It's my understanding that there is no clean dynamic
>> configuration mechanism that ties back to the address allocation
>> system (that is, to DHCP).
>>
>> It seems to me that what we are talking about here is exactly
>> analogous to what's done today in IPv4 with DHCP snooping and DHCP
>>  leasequery, both of which seem to be good solutions that are
>> widely deployed and work well for network providers.   If there's
>> a better way, I'm all ears, but when I asked in the routing area,
>> I got some pretty vague answers that sounded a lot like "it's
>> configured statically."
>
> One issue that comes to mind for me is that the DHCPv6 server may
> not, in fact, have complete information about the routing and prefix
>  aggregation information.  The DHCPv6 server would be inferring
> aggregation information from the pools of prefixes it has to
> delegate.  Looked at another way, there is likely an oracle of
> network configuration somewhere from which the delegated prefix pools
> and prefix aggregation for routing is derived.  The DHCPv6 server
> might be able to make an educated guess but it doesn't have
> necessarily authoritative information.
>
> Another issue with piggybacking is that the routing information may
> change independent of any specific DHCPv6 message exchanges (someone
>  else raised this issue), so that there would be noway to send
> updates if there was no DHCPv6 traffic to send through the router.
>
> Why would this aggregation information not be provided through
> whatever configuration mechanism is used to manage the router?
>
> - Ralph
>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2012 14:26:51 +0200

Le 05/09/2012 10:06, Ole Trøan a écrit :
> the DHCP server is not on the data path. unless one follows the model
> described in 3633 where the DHCP server is on the PE router.

I agree because our DHCP Server is not on the data path, but has the 
info about all data paths.

> I might be missing something here. I don't understand how the
> aggregate route for a set of delegated prefixes is dynamic. when and
> how could all subscribers within a aggregate move?

I dont think the aggregation relationship could be dynamic - it's frozen 
bitwise operation - 11 is prefix of 1101 whatever the routing is set up.

Alex

>> leasequery, both of which seem to be good solutions that are widely
>> deployed and work well for network providers.   If there's a better
>> way, I'm all ears, but when I asked in the routing area, I got some
>> pretty vague answers that sounded a lot like "it's configured
>> statically."
>
> hmm, I didn't think the IPv4 aggregate route was deduced or
> configured from DHCPv4 either. the deployments I'm aware of, the PE
> is always configured outside of DHCP with the IPv4 subnets /
> aggregate routes. what's the analogy?
>
> cheers, Ole
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2012 14:51:56 +0200

I think it should be adopted because I like the idea to avoid numerous
dynamic specific routes presumably introduced by the use of Prefix
Delegation for autoconfiguring mobile routers on a large scale.

But I also think that some of the problem of too many specific routes in
the dynamic routing protocol generated by Relay could be avoided with
help from (1) a better address planning by a human and (2) less computer
intelligence at Relay.

To me it also depends on the willingness of authors to push forward and
of group members to help find consensus.

Let's see further,

Alex

Le 24/08/2012 17:32, Ted Lemon a écrit :
> The authors have proposed that the working group adopt the prefix
> pool option draft as a working group item.   We have engaged in some
> correspondence with participants in the Routing Area, and while some
> helpful advice was given, no objections were raised to going forward
> with the work, and it's a DHCP protocol extension, so it makes sense
> for it to happen in the DHC working group.
>
> The document proposes an extension to the DHCP protocol that allows
> the DHCP server to communicate prefixes to the provider edge router
> when doing prefix delegation, such that this router can advertise a
> route to an aggregate prefix, rather than to many individual
> prefixes, and so that this router does not have to perform ad-hoc
> prefix aggregation, which may produce less optimal results.
>
> please reply to this message saying so.   If you think this work
> should not be adopted by the working group, please reply to this
> message saying so.   We will evaluate consensus on September 7.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Sep 2012 13:20:28 +0000

> advertise the aggregated prefix instead of numerous specific routes.

I think the whole point of the prefix pool option is to avoid making educated guesses, by coming up with the aggregate route in the core of the network, as a management function.   IOW, I don't think the DHCP server will be following some heuristic to figure out what the aggregate prefix is; rather, it will be configured either to allocate one specifically, or will be configured by a management system with a predefined prefix pool.

---

From: Ole Trøan <[email-masked]>
Date: Fri, 7 Sep 2012 17:30:42 +0200

Alex,

[...]

> more intelligent (i.e. "snoop").

the _aggregate route_ (i.e the route covering the PD prefixes) installation and redistribution in an IGP is typically done with manual configuration on the PEs.

route injection by PD itself, is typically done by DHCP snooping.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Sep 2012 15:39:51 +0000

> the _aggregate route_ (i.e the route covering the PD prefixes) installation and redistribution in an IGP is typically done with manual configuration on the PEs.

Right.  This is a proposal to do it differently.

---

From: "Leaf Yeh" <[email-masked]>
Date: Sat, 8 Sep 2012 00:06:51 +0800

Ole - the _aggregate route_ (i.e the route covering the PD prefixes)
installation and redistribution in an IGP is typically done with manual
configuration on the PEs.
route injection by PD itself, is typically done by DHCP snooping.

Agreed the above if we don't have draft (OPTION_PREFIX_POOL). :-)

DHCPv6-PD inject the dynamic routes per the lease of delegated prefixes,
while the draft (OPTION_PREFIX_POOL) help to inject the *dynamic*
aggregation route per the *status* of the prefix pool. (See the definition
of *status* in Section 4 ) 

All the configuration for the necessary aggregation routes (on the relay)
per the prefix pools (and its status) turns to be automatic after employing
the mechanism newly introduced in this draft.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ole Tr?an
Sent: Friday, September 07, 2012 11:31 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [dhcwg] Call for Adoption:
draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Alex,

[...]

>> this does not solve the DHCPv6 PD problem of route injection. a route 
>> needs to be installed per client, and snooping is still needed for 
>> that. this proposal _only_ solves the problem of installing an 
> (i.e. existing single prefixes in PD require snooping and pool-opt 
> draft requires it too).
> 
> Well no, static configuration at Relay is not sufficient for PD to 
> work, even if we dont talk pool-opt draft - there is a need of that 
> route at Relay.  There is no other solution to that than DHCP Relay to 
> become more intelligent (i.e. "snoop").

the _aggregate route_ (i.e the route covering the PD prefixes) installation
and redistribution in an IGP is typically done with manual configuration on
the PEs.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 08 Sep 2012 18:17:11 +0200

Hello Ole,

I meant the following below...

Le 07/09/2012 17:30, Ole Trøan a écrit :
>>> PE/relay.
>> In a sense I agree - this proposal seems to still require
>> snooping. (i.e. existing single prefixes in PD require snooping and
>> pool-opt draft requires it too).
>>
>>  work, even if we dont talk pool-opt draft - there is a need of
>> that route at Relay.  There is no other solution to that than DHCP
>> Relay to become more intelligent (i.e. "snoop").
>
> the _aggregate route_ (i.e the route covering the PD prefixes)
> installation and redistribution in an IGP is typically done with
> manual configuration on the PEs.
>

I meant to say that DHCP snooping is needed anyway to insert a route in
the routing table at Relay, with respect to the allocated prefix during
a regular PD operation - that route is about the allocated prefix and
the next hop being the address of the Requesting Router.

Whether that particular route gets distributed in the core is a question
which when there are many  such routes it be big.

But 'snooping' must already be there for that route in the Relay.

(if I understand correctly this 'snooping' behaviour).

The logic would be that if snooping is already there then it wouldn't be
the fault of this draft about it.

But I think this is already clarified by recent days discussions on this
topic, no need for me to insist.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 08 Sep 2012 18:18:38 +0200

Le 07/09/2012 15:20, Ted Lemon a écrit :
>> I mean I dont think an educated guess could be done reasonably to
>> form a common prefix and instruct the Relay about it.  Even less
>> that Relay to advertise the aggregated prefix instead of numerous
>> specific routes.
>
> I think the whole point of the prefix pool option is to avoid making
> educated guesses, by coming up with the aggregate route in the core
> of the network, as a management function.   IOW, I don't think the
> DHCP server will be following some heuristic to figure out what the
> aggregate prefix is; rather, it will be configured either to allocate
> one specifically, or will be configured by a management system with a
> predefined prefix pool.

Ok, I understand now.  It makes sense what you explain above.

On another hand, the idea of a Relay to act first as a Requesting Router 
has already been discarded somehow?

Alex

---

From: Ted Lemon <[email-masked]>
Date: Sat, 8 Sep 2012 16:43:09 +0000

On Sep 8, 2012, at 12:18 PM, Alexandru Petrescu <[email-masked]> wrote:
> On another hand, the idea of a Relay to act first as a Requesting Router has already been discarded somehow?

That may well be a valid configuration in some settings, but for an ISP, particularly with legal record-keeping mandates, doing CPE prefix allocation in the core of the network makes more sense.   Also, by doing it this way, the PE router can be simpler and cheaper.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Sep 2012 03:05:17 +0000

> If you think this work should be adopted by the working group, please reply to this message saying so.   If you think this work should not be adopted by the working group, please reply to this mess…

There were a few comments, and I think there's at least one person who opposed adopting this work, and perhaps two others who are on the fence about it but didn't say specifically.   But there are also seven people in favor of adopting the work.   Since this is a call for adoption, and not a working group last call, I think that this means that there is a rough consensus that we should do this work.   Hopefully the people who had comments will work with Leaf to improve the draft.

Thanks!