RE: [EFM] Discovery (it was OAM...)
Andrew,
Sorry, I never use my PacBell account, doesn't work out with my dsl router
and PPoE.
Bob
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Andrew
Smith
Sent: Friday, September 07, 2001 1:14 PM
To: Bob Hines
Cc: stds-802-3-efm@ieee.org
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-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]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;
seto.koichiro@hitachi-cable.co.jp; stds-802-3-efm@ieee.org; Dolors Sala
Subject: RE: [EFM] Discovery (it was OAM...)
Faye,
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.
Bob
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Faye Ly
Sent: Friday, September 07, 2001 10:03 AM
To: carlosal@xxxxxxxxxxxxxxxxxx
Cc: Francois Menard; Carlos Ribeiro; Geoff Thompson;
seto.koichiro@hitachi-cable.co.jp; stds-802-3-efm@ieee.org; Dolors Sala
Subject: RE: [EFM] Discovery (it was OAM...)
Carlos,
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:
http://www.internetweek.com/newslead01/lead080201.htm
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.
-faye
-----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;
seto.koichiro@hitachi-cable.co.jp; stds-802-3-efm@ieee.org;
carlosal@xxxxxxxxxxxxxxxxxx; Dolors Sala
Subject: RE: [EFM] Discovery (it was OAM...)
Faye,
Warning: this message is not directly related to EFM, but it explains
the
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
for
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
the
end user and the service provider for IP services,such as Internet
access.
It's a very good way to provision services in the DSL world. In fact,
many
DSL providers have turned to PPPoE as the standard solution for
connectivity. One of the advantages of the PPPoE solution for DSL is
that
it allows to implement a tunnel traversing different technologies:
Ethernet
inside the user home, ATM into the DSL network, with the termination
being
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
with
very low overhead (a few extra bytes per packet, tipically less than 3%
of
the payload). These connections make easy to implement a flexible
service
selection paradigm, where the user can chose the ISP at time of
authentication.
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
mass
deployment. The amount of configuration is negligible, the flexibility
is
excelent, and the cost is very, very low. The termination box is
normally
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
and
protocols.
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
cut
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
security.
You can solve this problems by breaking the network into smaller blocks.
In
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
PPPoE
solution.
-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
to
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
access
services, but it's not well suited for broadcast/multicast based
services,
such as video delivery; it simply does not scale very well. My opinion
is
that the basic EFM design should not assume that any of the solutions
above
is going to be adopted as the standard solution for service provisioning
anytime soon.
Carlos Ribeiro
CTBC Telecom