Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Discovery (it was OAM...)


Sorry, I never use my PacBell account, doesn't work out with my dsl router
and PPoE.


-----Original Message-----
[]On Behalf Of Andrew
Sent: Friday, September 07, 2001 1:14 PM
To: Bob Hines
Subject: RE: [EFM] Discovery (it was OAM...)

Bob - you're reading too much between the lines. Just for the record, I have
no connection with PacBell. Well actually I do have an intermittent
connection with them as my (effective monopoly) last-mile DSL and phone
provider :-). I also use them as my ISP and they're actually very good at
that layer of the pie.

Andrew Smith
(no corporate affiliation - this space not for rent etc.)

-----Original Message-----
[]On Behalf Of Bob Hines
Sent: Friday, September 07, 2001 11:21 AM
To: Faye Ly; carlosal@xxxxxxxxxxxxxxxxxx
Cc: Francois Menard; Carlos Ribeiro; Geoff Thompson;;; Dolors Sala
Subject: RE: [EFM] Discovery (it was OAM...)


SBC has been deploying this service for awhile now, as a DSL PPoE user in
the PacBell region it was very easy on me to install and bring up, but from
other threads, Andrew at PacBell seams to feel its not so easy from the
carriers perspective. Also when it broke once I found it was faster to order
a new line and reinstall than it was to wait for the repair date.  Maybe the
issue is its very difficult to maintain and troubleshoot if it breaks,
however, my outage was caused by an internal administrative error, not as
technological one.


-----Original Message-----
[]On Behalf Of Faye Ly
Sent: Friday, September 07, 2001 10:03 AM
To: carlosal@xxxxxxxxxxxxxxxxxx
Cc: Francois Menard; Carlos Ribeiro; Geoff Thompson;;; Dolors Sala
Subject: RE: [EFM] Discovery (it was OAM...)


Thank you very much for the clarification.  It's nice to hear it from
the carrier's perspective.  I wonder have you heard the big stir about
SBC's decision to go with PPPoE?  Please check out:

And you are right, this is out of scope of this forum and maybe we
should bring the discussion off-line.  I will send you separate email
regarding this.


-----Original Message-----
From: carlosal@xxxxxxxxxxxxxxxxxx [mailto:carlosal@xxxxxxxxxxxxxxxxxx]
Sent: Thursday, September 06, 2001 11:52 AM
To: Faye Ly
Cc: Francois Menard; Carlos Ribeiro; Geoff Thompson;;;
carlosal@xxxxxxxxxxxxxxxxxx; Dolors Sala
Subject: RE: [EFM] Discovery (it was OAM...)


Warning: this message is not directly related to EFM, but it explains
particularities of the PPPoE model, that is a very popular way to deploy
data services for DSL and cable networks. It is a potential application
the EFM solution.

The original message regarding PPPoE was mine. It has nothing to do with
OAM at the link level; it is used to provision the connectivity between
end user and the service provider for IP services,such as Internet
It's a very good way to provision services in the DSL world. In fact,
DSL providers have turned to PPPoE as the standard solution for
connectivity. One of the advantages of the PPPoE solution for DSL is
it allows to implement a tunnel traversing different technologies:
inside the user home, ATM into the DSL network, with the termination
handled by a special aggregation box with ATM interfaces.

The reason why I cited PPPoE is that it is a very good solution from the
service provider standpoint. It allows to stablish dynamic connections
very low overhead (a few extra bytes per packet, tipically less than 3%
the payload). These connections make easy to implement a flexible
selection paradigm, where the user can chose the ISP at time of

Looking strictly from an engineering standpoint, the solution may seem
awkward. After all, why tunnel another L2 protocol over the Ethernet
network? After working with several types of access networks in the past
few years, I can tell you that no other technology is best suited for
deployment. The amount of configuration is negligible, the flexibility
excelent, and the cost is very, very low. The termination box is
able to to a lot of valued added services, including content delivery,
firewall, bandwidth management, and so on. Compatibility is not an issue
either, as all the basic requirements are fulfilled by open standards

In short, the use of a 'virtual' L2 topology makes the network much more
flexible. It does not matter if the customer is connected through DSL,
cable modem, dial up or fiber. The tunnels can be stablished directly
between the endpoint and the service management gateway, using either
PPPoE, PPPoA, or even L2TP, as all the protocols are closely related.

(on the other hand, the proposed alternative - 802.1X - doesn't quite
it; it's bound to the Ethernet world. The 'PPPoX' familiy makes
interoperability easier)

Let us look at the issue from other sides; there are some alternatives,
such as the flat network with DHCP, and fully IP-based networks.

- The flat network has some serious problems with scalability and
You can solve this problems by breaking the network into smaller blocks.
fact, if you keep breaking the network until you have a 1:1 relation
between the endpoints, then the scenario becomes very similar to the

-The full IP solution looks nice on paper, but it does have serious
limitations. The IP address allocation is difficult to manage, and it's
difficult to segregate the traffic of every individual customer to
guarantee specific service requirements. Tipically, the intelligence is
scattered all over the network in several routers, making it much harder
manage. The solution in this case is to deploy big 'access routers' into
the network, and to connect every user to a dedicated interface. Again,
going this road takes us exaclty to the PPPoE scenario again.

Of course, there are still hot debates about the relative merits of each
solution. For example, PPPoE is very good for provisioning Internet
services, but it's not well suited for broadcast/multicast based
such as video delivery; it simply does not scale very well.  My opinion
that the basic EFM design should not assume that any of the solutions
is going to be adopted as the standard solution for service provisioning
anytime soon.

Carlos Ribeiro
CTBC Telecom