assigned to the PPP device.
Frank
-Original Message-
From: Sean Donelan [mailto:s...@donelan.com]
Sent: Saturday, October 31, 2009 3:14 PM
To: NANOG list
Subject: RE: PPPoE vs. Bridged ADSL
On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote:
> Others commented on things I already had in m
On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote:
Others commented on things I already had in mind only the username/password
thing of PPPoE. We use the same username/pw on the modem as the customer
users for their e-mail, so a password change necessitates a truck roll (I
know, I know, TR-069).
On Thu, 29 Oct 2009, Vince Mammoliti wrote:
This current draft
DHCP Authentication
http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt
That's what makes protocol wars so much fun. With enough options, almost
any protocol can do almost anything.
As you know, I did my best to kill PPPOx
2009 10:03 AM
To: nanog@nanog.org
Subject: Re: PPPoE vs. Bridged ADSL
Mikael Abrahamsson wrote:
> I think the important thing is to have a separate L2 isolation per
> customer so you can more easily deploy IPv6 in the future. q-in-q or
> PPPoX will both solve this problem, but deployin
On Thu, Oct 29, 2009 at 11:10 AM, Jack Bates wrote:
> *dreams of a secure authenticate once world*
It may be worth noting here that there are times were one wants
barriers between automation to keep malfunction or malice from
spreading too far without human involvement.
Of course, most of th
cket.net]
Sent: Wednesday, October 28, 2009 4:21 PM
To: NANOG list
Subject: PPPoE vs. Bridged ADSL
There is a debate among our engineering staff as to the best means of
provisioning broadband service over copper facilities. Due to our
history, we have a mix out in the field. Some customers are on
Vince Mammoliti wrote:
This current draft
DHCP Authentication
http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt
Adds the username/password that PPP has to DHCP and I believe support IPv6.
Now if we could just tweak things perfectly so customers can hook up,
log in
Mikael Abrahamsson wrote:
I think the important thing is to have a separate L2 isolation per
customer so you can more easily deploy IPv6 in the future. q-in-q or
PPPoX will both solve this problem, but deploying multicast TV offering
might be harder in this deployment model.
In general, it sh
29, 2009 5:07 AM
To: nanog@nanog.org
Subject: Re: PPPoE vs. Bridged ADSL
On Wed, 28 Oct 2009, David E. Smith wrote:
> With PPPoE, however, the end-user can't just plug in and go - they'll
> have to configure their PC, or a DSL modem, or something. That means a
> phone call t
On Wed, 28 Oct 2009, David E. Smith wrote:
With PPPoE, however, the end-user can't just plug in and go - they'll have
to configure their PC, or a DSL modem, or something. That means a phone call
to your tech support, most likely. In many cases, DHCP can lead to
plug-and-play simplicity, which mea
On Wed, 28 Oct 2009, JD wrote:
I think the important thing is to have a separate L2 isolation per
customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX
will both solve this problem, but deploying multicast TV offering might be
harder in this deployment model.
There is re
Apologies if this message is brief, it is sent from my cellphone.
On 29/10/2009, at 11:33, Walter Keen
wrote:
Most aDSL modems if set to PPPoE (I think Actiontec's come this
way by
default) will send the mac as the pppoe un/pw.
David E. Smith wrote:
Opinions on this? I'd be inter
On Wed, 28 Oct 2009 15:33:58 -0700
Walter Keen wrote:
>Most aDSL modems if set to PPPoE (I think Actiontec's come this way by
>default) will send the mac as the pppoe un/pw.
>David E. Smith wrote:
>
> Opinions on this? I'd be interested in hearing the latest real world
> experience f
We like PPPoE on the edge because we can use RADIUS to apply policy to
the subscribers for bandwidth management, class-of-service, SNPs, etc.
You probably have some of these features via your DSLAM, but we found
it easier to do via RADIUS with a web based GUI for our provisioning
folks. So
Most aDSL modems if set to PPPoE (I think Actiontec's come this way by
default) will send the mac as the pppoe un/pw.
David E. Smith wrote:
Opinions on this? I'd be interested in hearing the latest real world
experience for both and the direction most folks are going in.
I can't speak to
>
> Opinions on this? I'd be interested in hearing the latest real world
> experience for both and the direction most folks are going in.
>
> I can't speak to which would be better on copper specifically, but in
general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff
will be simil
On Cisco hardware PPPoE was cleaner if you have other ISPs' customers on
your network and you want to put them in their own VRF's. I've been out of
that world for a while now, so maybe it's changed.
-saxon
2009/10/28 JD
> There is a debate among our engineering staff as to the best means of
> p
JD wrote:
There seem to be pros and cons to both directions. Certainly true
bridging has less overhead. But modern CPEs can minimize the impact of
PPPoE. PPPoE allows for more flexible provisioning; including via
RADIUS. Useful for the call center turning customers on/off without NOC
help. But
There is a debate among our engineering staff as to the best means of
provisioning broadband service over copper facilities. Due to our
history, we have a mix out in the field. Some customers are on DSLAMS
set up for bridged connections with DHCP; isolated by a variety of means
including VLANS.
19 matches
Mail list logo
