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

RE: [EFM] OAM developing Geoff's observation.

What I understood is that:
TL1 is a scripting method that provides both management protocol
and management objects.  
So question:
If we define a set of managed objects for EFM, can TL1 takes them
and standardize it as easily as MIB (using SNMP) or IDL (using CORBA)?
-----Original Message----- 
From: Roy Bynum 
Sent: Mon 9/17/2001 2:19 PM 
To: Fletcher E Kittredge 
Subject: Re: [EFM] OAM developing Geoff's observation.

	I do not want you to take this the wrong way.
	You are prime example of the skew that has been prevalent in the
	about the services market.  As an IP services provider, you have
a certain
	set of requirements.  At present, it is very likely that you
deploy your
	service infrastructure over some other service providers'
	trunks, or you have your own high speed long haul
infrastructure.  Using
	the OSI model of protocol peering, L3 IP services only need IP
	management to be supportable.  The irony is that the most common
	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.
	There are other services than IP that need to be supported by
EFM.  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.
	Thank you,
	Roy Bynum
	At 04:38 PM 9/17/01 -0400, Fletcher E  Kittredge wrote:
	>On Mon, 17 Sep 2001 13:55:18 -0500  Roy Bynum wrote:
	> > There are a lot of ISP based SPs that are creating a lot of
noise.  Is it
	> > because they are falling prey to the ".com" syndrome?  Could
it be that
	> > they do not have the ability to deliver a high margin
service and do not
	> > want others to realize that?  What about the rest of the
	> industry?  What is
	> > the reality of the rest of the industry?  What are service
	> for
	> > business versus those for residential?
	>         I think I understand (and share) your frustration with
	>industry.  However, I think it is dangerous to make assumptions
on why
	>businesses fail, or on the industry as a whole, by
concentrating on a
	>few well publicized cases.  It is also dangerous to make
	>about how competitive a particular product is based on the
health of
	>the vendor as a whole.  HP can sell great printers but if the
rest of
	>their product line is in the crapper, they are out of business.
	>my perspective, the reason these ISP based SP's have gone out
	>business has nothing to do with IP, but rather that they were
	>businesspeople.  Also, I couldn't help but notice they weren't
	>good IP engineers...  Lots of inexperienced folk jumped into
	>         So, companies like ours have been successful in our
	>niche.  We make money selling high speed IP services.  I don't
	>we are shy about explaining what we do and how we do it.  In
fact, I
	>worry sometimes that we say too much...  I feel both GWI and
	>Trails have given back to the community by publicizing the
reasons for
	>our success, and giving others a chance to copy and potentially
	>compete with us.  Traditionally, sharing knowledge this is the
	>Internet way.
	>         You are most correct that business requirements may
	>from residential.  I would not want to claim otherwise.
	> > Think about this simple fact.  The vast majority of small to
medium size
	> > businesses that have multiple sites on an enterprise
network, use several
	> > "Private Line" or "Virtual Private Line" links to make up
their enterprise
	> > networks.  Most of them however only have one Internet type
link.  If
	> > people simple think thing through and realize how their own
	> > networks are deployed, they would realize what the real
priority for EFM
	> > supporting business deployment should be.  In this
environment slightly
	> > higher costs can be justified to obtain better efficiency.
	>I respectfully disagree on this point.  We don't build our
	>this way.  I am not asking you to agree with me.  I am asking
you to
	>treat my perspective with the same respect I treat yours.  What
	>would like to see is an EFM which would allow you to build QoS
	>your network, and us not to use your QoS mechanisms.  Then we
can let
	>the market decide the argument, not a vote of a standards
	>It may be that there is no way to build QoS without inserting
it into
	>EFM.  However, before adding complicated QoS mechanisms I would
	>to see significant proof that it is necessary and at least two
	>prototypes of the mechanism; prototypes which can be easily
	>For an IP connection, QoS on one part of a TCP/IP link does not
	>much value.  QoS must be end-to-end to be effective.
	> > For deployment to residential services, there are other
issues.  Only the
	> > voice service is symmetrical.
	>One data point to back up your conclusion, over the last five
	>for our high speed residential IP services we see a fairly
steady 10:1
	>incoming to outgoing.
	>However, a lesson I have been taught again and again over the
last 15
	>years is that you can't predict the traffic patterns of the
	>We got into the ISP business before the growth of the web and
	>I thought the web was an insignificant toy.  Our world changed
	>the web became widespread.  None of us know what the next
killer app
	>will be.  I don't feel comfortable predicting future values
based on
	>past performance.
	>Fortunately, both IP and Ethernet handle changes in traffic
	> >  The Internet service to residential
	> > customers is normally very asymmetrical.  The
video/broadcast services are
	> > simplex.  This will make for a very different infrastructure
and cost
	> model
	> > than business services.  Other than for the voice, PPPoE may
work very
	> > well.
	>Peer-to-peer traffic such as gaming and
	>applications are our biggest driver of high speed, low latency
	>residential services.  None of us can predict the next killer
	>app... but my gut is that it will not be VoIP nor traditional
	>Spend some time with a teenager and you may develop the same
	>By the way, this teenage peer-to-peer stuff took us by suprise.
	>used to have some of the local traffic filters other SPs have
	>about on our networks.  We learned the hard way that kids these
	>want low latency, high speed links internal to their town.  If
	>make their packets take the long way round, they will drop you
like a
	>hot potato in order to switch to the local cable company...
What is
	>how you say it "low ping bastard?"
	> > The real question is, can a service provider make any money
in this
	> > domain?
	>Yes, we do make money currently and for the last number of
years.  I
	>hope we will continue to make money.  But the future is always
	>uncertain.  I am trying to "make my own luck" by participating
in this
	>sincere and most respectful regards,