RE: [EFM] OAM developing Geoff's observation.
Faye,
TL1 is a formatted ASCII string messaging language that was originally used
over and for X.25. It predates object oriented technology. It even
predates SONET. EFM would not want to standardize on TL1. There is at
least one vendor that has, however, translated various MIBs into TL1
language, allowing service providers all over the world to support their
technology.
Thank you,
Roy Bynum
At 05:41 PM 9/17/01 -0700, Faye Ly wrote:
>Roy,
>
>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)?
>
>-faye
>
>-----Original Message-----
>From: Roy Bynum
>Sent: Mon 9/17/2001 2:19 PM
>To: Fletcher E Kittredge
>Cc: bob.barrett@fourthtrack.com; stds-802-3-efm@ieee.org
>Subject: Re: [EFM] OAM developing Geoff's observation.
>
>
>
>
> Fletcher,
>
> I do not want you to take this the wrong way.
>
> You are prime example of the skew that has been prevalent in the
>commentary
> 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'
>inter-machine
> trunks, or you have your own high speed long haul
>infrastructure. 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.
>
> 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
>requirements
> > for
> > > business versus those for residential?
> >
> >Roy;
> >
> > I think I understand (and share) your frustration with
>the
> >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
>assumptions
> >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.
>From
> >my perspective, the reason these ISP based SP's have gone out
>of
> >business has nothing to do with IP, but rather that they were
>lousy
> >businesspeople. Also, I couldn't help but notice they weren't
>very
> >good IP engineers... Lots of inexperienced folk jumped into
>the
> >market...
> >
> > So, companies like ours have been successful in our
>market
> >niche. We make money selling high speed IP services. I don't
>think
> >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
>Oregon
> >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
>differ
> >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
>enterprise
> > > 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
>networks
> >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
>I
> >would like to see is an EFM which would allow you to build QoS
>into
> >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
>commitee.
> >
> >It may be that there is no way to build QoS without inserting
>it into
> >EFM. However, before adding complicated QoS mechanisms I would
>like
> >to see significant proof that it is necessary and at least two
>working
> >prototypes of the mechanism; prototypes which can be easily
> >reproduced.
> >
> >For an IP connection, QoS on one part of a TCP/IP link does not
>add
> >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
>years,
> >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
>customer.
> >We got into the ISP business before the growth of the web and
>frankly
> >I thought the web was an insignificant toy. Our world changed
>when
> >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
>patterns
> >well.
> >
> > > 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
>teenage-girl-to-teenage-girl
> >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
>video.
> >Spend some time with a teenager and you may develop the same
> >intuition.
> >
> >By the way, this teenage peer-to-peer stuff took us by suprise.
>We
> >used to have some of the local traffic filters other SPs have
>talked
> >about on our networks. We learned the hard way that kids these
>days
> >want low latency, high speed links internal to their town. If
>you
> >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
> >forum.
> >
> >sincere and most respectful regards,
> >fletcher
>
>