Subject: [dhcwg] Call for adoption: draft-korhonen-dhc-pd-exclude

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Sep 2010 10:08:11 -0700

There's been quite a bit of discussion of this draft on the mailing list since Maastricht, and it's within the charter for the working group.   Are there any objections to adopting this as a working group item?

(If I don't hear anything by Friday evening, I'll take it as a yes, although it would be nice if the interested parties would chime in).

---

From: Jyrki Soini <[email-masked]>
Date: Thu, 23 Sep 2010 13:50:53 +0300

> (If I don't hear anything by Friday evening, I'll take it as a yes, although it would be nice if the interested parties would chime in).

I support adopting this draft as working group draft.
It is quite simple extension, backward compatible and a working solution
to a real problem.
--
Jyrki Soini

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 27 Sep 2010 12:21:48 -0700 (PDT)

Hi Ted,
  My concern with this draft is that the draft wants to enable every Internet 
phone to become an RR and do the stateful DHCPv6 PD. My thinking is that such a 
thing is not scalable from the point of view of number of hosts and from the DRs 
(DHCPv6 servers) point of view. I argue that no SDO will accept to adopt such a 
solution.
  The authors (or a subset) had earlier proposed to do stateless PD at the 
hosts. That idea made much better sense. I wonder what happened to that?

Regards,

Behcet

----- Original Message ----
> From: Ted Lemon <[email-masked]>
> To: "[email-masked] Group" <[email-masked]>
> Sent: Mon, September 20, 2010 12:08:11 PM
> Subject: [dhcwg] Call for adoption: draft-korhonen-dhc-pd-exclude
> 
> There's been quite a bit of discussion of this draft on the mailing list since  
>Maastricht, and it's within the charter for the working group.   Are there  any 
>objections to adopting this as a working group item?
> 
> (If I don't hear  anything by Friday evening, I'll take it as a yes, although 
>it would be nice if  the interested parties would chime  in).
> 
> _______________________________________________
> dhcwg mailing  list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: <[email-masked]>
Date: Mon, 27 Sep 2010 21:42:11 +0200

Yes, Support the adoption of this I-D as a WG item.

-Raj

---

From: Ole Troan <[email-masked]>
Date: Mon, 27 Sep 2010 21:59:50 +0200

Bechet,

> (DHCPv6 servers) point of view. I argue that no SDO will accept to adopt such a 

the draft doesn't say anything about phones... in any case I doubt that a modern phone would have issue with running a DHCP state machine.

> hosts. That idea made much better sense. I wonder what happened to that?

"stateless PD" is something you should take with a grain of salt. the state has to be kept somewhere.

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 27 Sep 2010 13:24:55 -0700 (PDT)

Hi Ole,

----- Original Message ----
> From: Ole Troan <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: Ted Lemon <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Mon, September 27, 2010 2:59:50 PM
> Subject: Re: [dhcwg] Call for adoption: draft-korhonen-dhc-pd-exclude
> 
> Bechet,
> 
> the draft doesn't say anything about phones... in any case I  doubt that a 
>modern phone would have issue with running a DHCP state  machine.

I think you confused my comment below with the one above.
The issue is a single DHCP server as DR serving potentially large number of end 
hosts as RR.
I don't think such a solution is good engineering, neither desirable.

There is simply no need for such a thing :-).

>has to be kept somewhere.

In that draft, they stated that DHCPv6 PD is stateful and they proposed a 
stateless PD in which the host delegates itself the prefixes without a need to 
go to the DR.

Regards,

Behcet

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Sep 2010 14:54:05 -0700

> There is simply no need for such a thing :-).

This is kind of a weird objection.   Clearly the authors of the draft have some reason for building the thing the draft documents.   Perhaps it would be more fruitful to discuss whether this is the right way to address the use case they are addressing with this draft, rather than simply dismissing whatever their use case is as nonexistent?   I mean, if they don't actually *have* a use case, then your point would prevail, but I assume they do or they wouldn't have bothered to make the proposal!

---

From: jouni korhonen <[email-masked]>
Date: Tue, 28 Sep 2010 08:58:22 +0300

Dear Bechet,

> (DHCPv6 servers) point of view. I argue that no SDO will accept to adopt such a 

A protocol doing/enabling one thing does not say what a provider on the operational side would allow/enable for its customer. I don't understand your scalability concern here to be honest.

> hosts. That idea made much better sense. I wonder what happened to that?

We moved on.. obviously for a reason.

- Jouni

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 Sep 2010 09:45:38 +0200

Bechet,

> I don't think such a solution is good engineering, neither desirable.

prefix delegation is by definition stateful, the state has to be kept somewhere. e.g. in the 6rd case it is kept in the IPv4 network.
as far as I've seen vendors have built DHCP servers that scale to a massive number of users/bindings/requests per second.
can you please provide numbers showing the scaling issue? and please give alternatives where you want the state to be kept?

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 28 Sep 2010 08:42:41 -0700 (PDT)

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>; Behcet Sarikaya 
><[email-masked]>
> Cc: Ole Troan <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Mon, September 27, 2010 4:54:05 PM
> This is kind of a weird objection.    Clearly the authors of the draft have 
>some reason for building the thing the  draft documents.   Perhaps it would be 
>more fruitful to discuss whether  this is the right way to address the use case 
>they are addressing with this  draft, rather than simply dismissing whatever 
>their use case is as  nonexistent?   I mean, if they don't actually *have* a use 
>case, then your  point would prevail, but I assume they do or they wouldn't have 
>bothered to make  the proposal!
> 

OK, using your logic, the same set of authors has made a draft about stateless 
PD. They did bother making one. It is at: 
http://tools.ietf.org/id/draft-savolainen-stateless-pd-01.txt in case you have 
not seen it.

Now they are making this proposal which is kind of the reverse proposal.

Can you please point out why you are picking up this one and not the other one?

The point is that authors make all sorts of proposals. It is up to the WG to 
advance it or not.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 28 Sep 2010 08:56:55 -0700 (PDT)

Ole, it depends on what type of interaction with the server.
Of course a large number of address assignment requests can be served with 
todays technologies.

Here you are talking about DHCPv6 PD, a real time application.

I understand that there might be a case for the mobile routers (MR) to do DHCPv6 
PD as RR. But that is a different story. There the mobile network prefixes are 
delegated and MNPs may not need the exclusion that draft-korhonen-dhc-pd-exclude 
proposes. The solution for MRs has already been developed over so many years, it 
is at http://tools.ietf.org/id/draft-ietf-mext-nemo-pd-06.txt. 

Regards,

Behcet

----- Original Message ----
> Sent: Tue, September 28, 2010 2:45:38 AM
> prefix delegation is by  definition stateful, the state has to be kept 
>somewhere. e.g. in the 6rd case it  is kept in the IPv4 network.
> as far as I've seen vendors have built DHCP  servers that scale to a massive 
>number of users/bindings/requests per  second.
> can you please provide numbers showing the scaling issue? and please  give 
>alternatives where you want the state to be kept?
> 
> cheers,
> Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Sep 2010 09:23:56 -0700

> Can you please point out why you are picking up this one and not the other one?

I'm not sure whether "you" here refers to me (the author of the message to which you are replying) or to the authors of the draft.   To be clear, I am not picking one or the other--it is the authors who have moved on from their previous proposal and now have a new proposal.

---

From: <[email-masked]>
Date: Wed, 29 Sep 2010 16:19:40 +0200

Hi,

I am the initial author of draft-savolainen-stateless-pd.. the biggest issues with that approach that I recall were:
1) It is another solution for the same problem
2) It would likely take too long time to make it to 3GPP Rel-10 (or even 11..)
3) The provisioning might require use of DHCPv6 client/server anyway (for OPTION_6SPD)
4) With stateless PD there is bigger risk that client and server somehow get out of sync (with stateful approach a bug in DR does not necessarily damage much, but in stateless approach it would more easily result in out of sync situation)
5) the DHCPv6 PD can be implemented to provide very similar solution:
* having lightweight implementations of DR at the first hop gateway and RR at the node
* gateway selecting prefixes for delegation exactly at the manner the Stateless PD described (for more efficient routing)
6) The people are already fixed on DHCPv6 PD and are not very eager to listen other options:)
7) Eight years too late?-) (Much of discussion leading to DHCPv6 PD seemingly took place at around 2002)

I think there was something else as well, which I don't recall immediately..

This DHCPv6 PD Exclude prefix option actually helps a lot to get benefits we sought with "stateless PD" out of stateful DHCPv6 PD domain.

Best regards,

Teemu

P.S. I also didn't manage to find much (but found some) support to the stateless approach in previous IETFs, but thank you for the support now:)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Sep 2010 08:04:43 -0700

> (If I don't hear anything by Friday evening, I'll take it as a yes, although it would be nice if the interested parties would chime in).

I said I would call this issue last Friday.   There has been one objection which, while past the deadline I set, is certainly within the timeframe that we are urged to allow for consensus calls (two weeks).

It seems to me that the consensus is leaning in the direction of adoption--we have one person dissenting.   I'd like to see the discussion with Behcet come to a conclusion, though, before calling the issue.   At the same time, these things shouldn't just be open-ended, and we have a draft submission cutoff for the -0 version of this document, should it be adopted, on the 18th of October.

So I'm basically asking the interested parties to try to hash this out and either agree to disagree, or be swayed, by next Friday, October 8.   If that doesn't happen, we'll re-evaluate on Friday, of course--this is a request, not a directive.   If the discussion comes to a conclusion before then, I'll make a determination on consensus at that time.

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 Sep 2010 17:24:21 +0200

Bechet,

> is at http://tools.ietf.org/id/draft-ietf-mext-nemo-pd-06.txt. 

I think we have different deployment scenarios in mind.

from my perspective the PD exclude option improves on RFC3633 and it is general enough that it can be used in any type of DHCPv6 PD deployment. be it broadband or something else. the pd-exclude draft does not specify any particular deployment scenario.

do you agree with the above paragraph?

if you are working on scenarios where DHCPv6 is not a suitable mechanism for prefix delegation, then I do not think this work is prohibiting or competing with such proposals.

given the above, do you still object to this becoming a working group draft? (if so could you please restate your objections?)

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Thu, 30 Sep 2010 10:16:37 +0300

Behcet,

> is at http://tools.ietf.org/id/draft-ietf-mext-nemo-pd-06.txt. 

*-nemo-pd defines how to use 3633 prefix delegation within 3963 NEMO context. This is clearly targeting to a different problem/use case than *-pd-exclude, which has nothing to do with network mobility as such but rather enhancing 3633 usability in wide scale of deployments. Do you agree on that?

I hope you realize that *-nemo-pd would actually need *-pd-exclude if the MR HoA should be taken from the prefix delegated to the MR.

- Jouni