Re: [EFM] OAM developing Geoff's observation.
I really am open to being convinced that OAM is necessary to
EFM. However, given the cost, it has to be a compelling argument.
This compelling argument has not yet been given voice.
I also understand that perhaps an mailing list is not the best
place to present such an argument. What might be necessary is a more
formal paper, with significant supporting data and information
necessary to evaluate the quality of the data.
On Mon, 17 Sep 2001 16:19:04 -0500 Roy Bynum wrote:
> You are prime example of the skew that has been prevalent in the commentary
> about the services market.
Since all we see is each other's words, it is hard not to make
assumptions based on those words. It may be best not to fall in
this trap though. I am probably a very different person than you
> As an IP services provider, you have a certain
> set of requirements.
Correct. Everyone has their own agenda. I have tried to make my
agenda as open and transparent. I try not to imply mine is the only
way or to speak for others. It is better that I don't speak for say,
banks running SNA because they understand their requirement better
than I. They should speak for themselves.
I do try to be aware of my prejudice and compensate by drawing on my
past. During the formative first five years of of my career I worked
on router hardware/software projects. For the next ten or so, I
worked on distributed systems built on top of IP, DECnet and ... SNA.
For the last eight years, I have primarily been working on
provisioning IP networks, mostly public IP networks.
> At present, it is very likely that you deploy your
> service infrastructure over some other service providers' inter-machine
> trunks, or you have your own high speed long haul infrastructure.
I thought EFM stood for Ethernet in the Final Mile and that the focus
of IEEE 802.3ah was on Ethernet Subscriber Access (ESA.) My apologies
if it is otherwise.
But to answer your question, our network is a real mix and the ratios
The fundamental property of IP is that it is that it is data layer
independent. This is the "Inter" in Internet. Leveraging this
independence can be powerful. It means that one does not have to be
trapped on say, the PSTN or the CATV or the wireless network. We
migrate quickly to where the service is fast, cheap and reliable. In
some places, we even light the fiber ourselves.
IP engineers get to know many data layers from widely varying sources.
CATV folk tend to have their way of thinking, LAN people a different
way, PSTN see the world from their view and wireless has a half dozen
sub-cults within their church. IP engineers get to listen to all the
above preach. Everyone has their opinions and no one wants to look at
the other guys.
> Using the OSI model of protocol peering, L3 IP services only need IP based
> management to be supportable. The irony is that the most common management
> language used by the L1 inter-machine trunk long haul infrastructure is not
> IP based, it is TL1. As far as I know, there are no MIBs defined for TL1
> by the IETF. There are a lot more TL1 managed systems in the world than
> there are systems that use IP based management.
Again I thought EFM stood for Ethernet in the Final Mile and
that the focus of IEEE 802.3ah was on Ethernet Subscriber Access
Since "legacy applications" are a consideration in any
project, "legacy applications" is a cheap argument and the last refuge
of an engineer with their back against the wall . If you are going to
play the "legacy applications" card, please back it up with data, lots
of data with sources and assumptions well documented. Be sure to run
your graphs out far enough in time to reach the point where EFM is in
wide deployment. Please be prepared to justify your dates.
> There are other services than IP that need to be supported by EFM.
Because of the focus on data layer independence, IP needs no EFM
services beyond the bare minimum which were in Ethernet circa 1980.
IP works best with minimal data layers which do not impose additional
> I am not suggesting using TL1. I simply trying to get everyone to
> realize that the overall data communications service provider world
> is bigger than just the IP services providers. What about all the
> banks in the world that still use SNA 3270 directly over Ethernet,
> in spite of the inroads that IP is making in the rest of the
> enterprise network environment.
I expect SNA will be with us a long time. I also suspect that
banks will not be using ESA (Ethernet Subscriber Access) as
a transport to their SNA networks. But these are my opinions only,
and I am offering no data to back them up. If you have actual data to
refute (or support) my guess about the longevity of SNA, I am all ears.