Subject: [dhcwg] EAPoDHCP notes

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Sep 2009 18:20:02 +0300

Hi Alan,

According to the DHC WG meeting notes:

	First, Alan DeKok gave his presentation, and made the following
	points:

	.

	    - Reason for not using PANA is that there aren't a lot of
servers
	      and clients deployed, not a lot of operational experience, and
	      the code to implement this protocol is small.   2000 lines of
	      code instead of 100,000.   Firmware upgrade still required,
but
	      much lower risk.

Wow, 100K lines of code! Where did you get that?

Also your slides said "Server and relay - Major network
Vendor" for implementation. This reads like "one" vendor, and does not
really justify the impression you gave above -- as if it is implemented by
multiple vendors and widely deployed, etc. 

Let's get the facts straight.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Sep 2009 18:47:39 +0300

> Alper Yegin wrote:
> ...
>   Experience.  Any networking daemon that does *anything* useful is
> about that size.

Ok, it is your guess than. 

But wait, why do you think EAPoDHCP does not require a daemon implementation
whereas PANA does?

>   Are you saying that there are PANA servers in wide-spread use that
> are
> significantly less than 100K LoC?

I didn't and don't say that.

>   So far as I know, there are multiple implementations.  

OK, can you name them? 

> Since it's
> new,
> I don't believe it is widely deployed.  Much like PANA.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Sep 2009 22:31:15 +0300

>   10+ years of experience writing multiple network daemons is not a
> "guess".
> 
>   That isn't what I said, and it isn't what I believe.
> 
>   The original comment was about code *changes*.  EAPoDHCP requires
> small amounts of code to change on a DHCP server/relay.  

Not sure why you omitted mentioning the "client".

> The rest is
> leveraging existing DHCP && RADIUS infrastructure.

I don't think there is any difference when it comes to leveraging existing
RADIUS infra. 

>   An alternate solution that was proposed was PANA.  Which is *not*
> deployed, which *does* require a new daemon implementation, and does
> not
> leverage existing infrastructure.

Which part of the infra are you referring to?

>   If there aren't functional PANA servers in wide-spread use, then my
> original comparison is valid.
> 
>   Cisco (obviously), and a few GPL projects.

Can you please provide pointers to the GPL projects? It'd be useful to see
what the code looks like when someone tries to implement EAPoDHCP.

Alper

>   Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 1 Sep 2009 23:57:15 +0300

Alan,

>   What I mentioned just above that remark: DHCP && RADIUS.

Of course PANA does leverage RADIUS. 
PANA does not really touch DHCP. This is a better leverage of the DHCP than
hacking it.

>   I don't have pointers to source.  Maybe a famous web search engine
> would help.

No it did not help. 
Can someone, anyone, give some names, pointers, etc. for the so-called "few
GPL projects" implementing EAPoDHCP? 

Thanks.

Alper

---

From: Richard Pruss <[email-masked]>
Date: Wed, 2 Sep 2009 07:08:02 +1000

> GPL projects" implementing EAPoDHCP?

Possibly it helps if I point out that they are not all based on our  
draft, and some are just "PAP in DHCP" and that in the
absence of standards guidance there is quiet a few vendor specific  
efforts.

- Ric

---

From: Alan DeKok <[email-masked]>
Date: Tue, 01 Sep 2009 17:32:25 +0200

...

  Are you saying that there are PANA servers in wide-spread use that are
significantly less than 100K LoC?

> multiple vendors and widely deployed, etc. 

  So far as I know, there are multiple implementations.  Since it's new,
I don't believe it is widely deployed.  Much like PANA.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 01 Sep 2009 18:48:35 +0200

> Ok, it is your guess than. 

  10+ years of experience writing multiple network daemons is not a "guess".

  The original comment was about code *changes*.  EAPoDHCP requires
small amounts of code to change on a DHCP server/relay.  The rest is
leveraging existing DHCP && RADIUS infrastructure.

  An alternate solution that was proposed was PANA.  Which is *not*
deployed, which *does* require a new daemon implementation, and does not
leverage existing infrastructure.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 01 Sep 2009 22:27:12 +0200

> Not sure why you omitted mentioning the "client".

  Because it's about the same amount of code.

  Alan DeKok.