Re: Broadband Subscriber Management

[William McCall <william.mccall () gmail com>]

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.