RE: Please help to clarify some things!
Roy, I agree that standards that have been put in place by the
ITU/T1/BellCore people differ from those in the IP data world. I strongly
disagree that the IP data world does not provide an adequate framework for
providing commercial data services that the enterprises that use them would
regard as mission critical. So from my point of view I can fully accept that
a difference exists as a fact but I am not in the least motivated to
accomodate this difference by wrecking the very successful foundation that
we have in the Ethernet world, nothing that has been said convinces me that
the difference represents a necessity for change on our part.
Mick
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Roy Bynum
Sent: Saturday, September 11, 1999 2:06 PM
To: mick@xxxxxxxxxxx
Cc: 'HSSG'
Subject: Re: Please help to clarify some things!
Mick,
I am not complaining about unreliable network management for IP data
services.
I was writing about a requirement as part of the ITU/T1/BellCore standards
that
the network management messaging communications for transmission systems be
fully reliable. This is something that IP data people have not had to deal
with. It comes down to a simple distinction between TCP based messaging and
UDP
based messaging. It involves the standards for out of band network
management
on commercial transmission systems instead of the inband network management
standard that is used on IP based data systems. I have worked on both types
of
systems and services for years. There is a difference. I have been
attempting
to get the IP data people to realize that the standards that are in place
for
commercial transmission systems and services are different than those for IP
based data systems.
Thank you,
Roy Bynum
MCI WorldCom
Mick Seaman wrote:
> Roy,
> Perhaps the telephone industry has not implemented it because the
telephone
> industry was already in existence and using management before Ethernet
came
> along?
>
> Seriously I don't think you are going to get anywhere on this mailer by
> complaining about the "unreliable delivery" of management information on
> this mailer. Such answers as exist have been well worked out for data
> networking equipment are in widespread use. Their study is not part of the
> development of Ethernet MACs. I would suggest that you learn some more
about
> the data networking world as it operates today, and about switched
Ethernet
> LAN deployment in particular, in parallel with teaching the rest of us
about
> the telecommunications world.
>
> You are missing Rich's point below. SNMP can communicate management
> parameters that have been collected. What needs to be done, in the
framework
> of the Ethernet/LAN/IP/SNMP, world is to identify what information needs
to
> be collected and how it is collected, and then to cast that information in
> the form of SNMP MIB so it can be transported using that protocol.
>
> Mick
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Roy Bynum
> Sent: Sunday, September 05, 1999 5:14 PM
> To: rtaborek@xxxxxxxxxxxxxxxx
> Cc: HSSG
> Subject: Re: Please help to clarify some things!
>
> Rich,
>
> If the methodology that is used for Ethernet is less expensive, why has
the
> telephony
> industry not implemented it? Could it be that the inband nature of IP
based
> SNMP
> network management on a particular link introduces more problems than it
> solves. SNMP
> uses UDP, not TCP so it is an unreliable information delivery system.
Could
> it be
> that the unreliable delivery of alarm and fault information is considered
> unreliable.
> If you have done any research, you would know that IP based out of band
> network
> management for telephony systems is based on TCP, UDP. TL1 over IP uses
> TCP.
>
> Ethernet does not gather any information at the optical level. The lowest
> common
> denominator for Ethernet network management is the "frame" not the optical
> path or
> signal. As such, any SNMP management system that is dependent on Ethernet
> as it is
> currently implemented does not have visibility to the optical level, not
> even
> indirectly.
>
> Thank you,
> Roy Bynum
> MCI WorldCom
>
> Rich Taborek wrote:
>
> > Roy Bynum wrote:
> >
> > > Mick,
> > >
> > > The splice points are just physical joinings of the fiber. The
problem
> is that
> > > they can be inconsistent to the point of effecting the functionality
of
> the data
> > > transmission. They can also be effected by people messing with them
in
> the
> > > process of working on the fiber cable. As a cable degrades or is
> damaged the
> > > link level may fail to the point of not being able to use "ping", yet
> the remote
> > > status information can inform you of whether the problem is in both
> directions
> > > of the traffic, or just one, and which one. A ping can not tell you
if
> the link
> > > failed in one direction only. As a transmission laser starts to fail,
> the remote
> > > system returning its receive status information can cause an
allert/trap
> against
> > > the local system, even though the problem was seen on the remote
system.
> >
> > Roy,
> >
> > Ethernet is at capable as SONET, at detecting the same conditions.
> Management
> > protocols above Ethernet are, in general, more capable of assisting
> service
> > personnel in maintaining links. I see no SONET advantage here. If
> anything, the
> > Ethernet advantage, once again, is lower cost.
> >
> > > At present, SNMP can only tell you if there are excessive error
frames.
> It does
> > > not have visibility at the optical level.
> >
> > I believe that SNMP stands for something like Simple Network Management
> Protocol.
> > Ethernet has visibility at the optical level. Ethernet gathers
information
> at the
> > optical level and SNMP presents the information for processing by a
> management
> > application. Therefore, SNMP indirectly has visibility at the optical
> level.
> >
> > > Having a network management system be
> > > able to properly report where the problem is will save a lot of time,
> effort,
> > > and expensive support people in the process of resolving the problem.
> Part of
> > > what I am recommending is adding to SNMP the visibility to the optical
> level.
> >
> > Too late.
> >
> > > Thank you,
> > > Roy Bynum
> > > MCI WorldCom
> > >
> > > Mick Seaman wrote:
> > >
> > > > Roy,
> > > >
> > > > I'm sorry, I feel you are repeating "full duplex 10Gb 802.3 is in
need
> of
> > > > protocol
> > > > level operations support functionality" but not adding to my
> understanding
> > > > of why at all. I am probably not alone.
> > > >
> > > > Can we be more specific about those things that the functionality
you
> > > > propose will enable us to diagnose that can not be accomplished by
> > > > collecting data in the systems attached to the Gigabit MAC and then
> sharing
> > > > that data or responding to queries using that MAC to transmit and
> receive.
> > > >
> > > > Is it possible to see or manage the splice points you refer to using
> an
> > > > embedded protocol? I thought they were just physical splice points
and
> that
> > > > none of the protocols you were discussing contained embedded OTDR.
So
> the
> > > > only thing that would help me to manage these would be better
insight
> into
> > > > BER or 'physical' level signal conditioning at the end stations. Why
> can't I
> > > > get at the information provided by this using SNMP, or check
> connectivity
> > > > using 'ping' etc. etc. What is there here that needs support in the
> MAC? It
> > > > may be that the world needs better management protocols but why is
> that a
> > > > subject for HSSG discussion?
> > > >
> > > > Mick
> > > >
> > > > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Roy
> Bynum
> > > > Sent: Sunday, August 29, 1999 10:24 PM
> > > > To: Henry Ngai
> > > > Cc: stds-802-3-hssg@xxxxxxxx
> > > > Subject: Re: Please help to clarify some things!
> > > >
> > > > Henry,
> > > >
> > > > In your document, your first and second drawings are somewhat
correct.
> I
> > > > doubt
> > > > that 10GbE would ever be implemented as you are showing it in your
> third
> > > > drawing. In your first drawing, you need to add a fiber plant that
> has
> > > > things
> > > > like splice points every 5 km at most, access to the fiber cable by
> people
> > > > that
> > > > have nothing to do with your data, and other issues. The
traditional
> 802.3
> > > > LAN
> > > > environment was outgrown when full duplex 802.3 over optical
transport
> was
> > > > standardized. It is even possible to take full duplex 100BaseFX
over
> WAN
> > > > distances with optical converters that are sold by several different
> > > > vendors.
> > > > As seen by individuals that are attempting to create manageable
> enterprise
> > > > level data networks with GbE, full duplex 10Gb 802.3 is in need of
> protocol
> > > > level operations support functionality in order to grow to its true
> > > > potential.
> >
> > --
> >
> > Best Regards,
> > Rich
> >
> > -------------------------------------------------------------
> > Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
> > Principal Architect Fax: 650 940 1898 or 408 374 3645
> > Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
> > 1029 Corporation Way http://www.transcendata.com
> > Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx