My understanding of the PPPoA/E deal is that SPs (originally) wanted to prevent some yahoo with a DSL modem from just being able to hook in to someone's existing DSL connection and using it, so they decided to implemement PPPoA and require some sort of authentication to prevent this scenario. At least one major vendor hold this to be the case, but I'm not sure if this is necessarily the case. Furthermore, a lot of the DSLAMs going out are GigE on the P side and ATM on the PE-CE. I can think of at least one or two issues with bungled ATM policing/shaping with a few vendors. In the case of my particular SP, they're performing the effective rate limiting at L1 anyway and terminating the PPPoA at the DSLAM so, in essence, they get to provide less throughput on the backend while advertising more (due to the inherent overhead of PPP and AAL5) Here's the output from my DSL training to show how they're doing it currently: Interleave Fast Interleave Fast Speed (kbps): 0 6016 0 768 This is my subscribed speed. RADIUS does add some nice features for usage monitoring but, here atleast, it was not a primary concern when it was first implemented (due to the 'unlimited' manner in which DSL was sold, the ability to get this per port, etc). --William
From: Larry Smith <lesmith@ecsis.net> Sent: Thursday, 23 April 2009 2:07:42 AM To: nanog@nanog.org CC: Subject: Re: Broadband Subscriber Management
On Wed April 22 2009 11:01, Curtis Maurand wrote:
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively.
Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any "technical" support to turn on/off customers.