Re: Data rate standards vs internal switching standards
Jonathan,
Can you organize a bunch of tutorials on this topic at the interim
and/or November meetings?
I looks like we need to be educated on this to be able to make a
decision. This topic has been holding up progress on a bunch of issues,
and we need to move forward. We can just ignore the issue (not
recommended), or we can at least try to understand it.
Martin Nuss
Roy Bynum wrote:
>
> Rich,
>
> Yes, I am avoiding a question that is too early to answer. The single
> biggest issue to me is that the majority of the group does not
> understand what extended and leased fiber systems and Native data
> communications services are, and what is required to do reliable
> implementations using them. At the end of your tutorial on MAS, I
> attempted to explain a major potential use and need for MAS. It was
> to determine the specific power requirements for spans of leased
> fiber. Your statements below indicate that you did not understand
> what I was trying to say. This in not unusual. I am very glad that
> you are learning more about SONET/SDH and what commercial service
> providers do to provide reliable services. Perhaps a broader
> understanding of the environment that 10GbE will find a major market
> in, will be achieved at the September meeting.
>
> You acknowledge that Ethernet and fibre channel technologies do not
> have the ability to support any cable or fiber facility that is not
> directly owned by the user, that includes 1000BaseLX. What you may
> not be aware of is the amount of leased fiber implementations of
> 1000BaseLX (GbE) and the push in the market for providing Native data
> transport services. It is my understanding that this forum does not
> allow referencing company's names otherwise I would refer you to
> several GbE that are implementing such systems for their customers. I
> will refer you to the July 20 Network World article about a school
> system that has implemented a MAN using fiber leased from a utility
> company. This is just one of those enterprise customers that are
> looking at optical networking as an alternative to traditional data
> telecommunications services. The amount of leased fiber and
> wavelengths that will be available to enterprise customers over the
> next few years is staggering compared to what was available last
> year. This is a major potential market for 10GbE.
>
> The combinations of long haul Native data transport, leased fiber, and
> leased wavelengths will provide major expansion of the role of 802.3
> in the market place. The role of switching 802.3 instead of routing
> in the enterprise network space will be expanding dramatically in the
> next few years. If it is structured properly, 10GbE will have a major
> role in that. If it is not structured properly, it will not. Until
> more people that are in HSSG, understand what the implementation
> requirements are for the customers using the expanded services and
> their service providers, I will attempt to avoid the issue of a
> compromise on a variable IPG.
>
> Thank you,
> Roy Bynum
> MCI WorldCom
>
>
>
> Rich Taborek wrote:
>
> > Roy,
> >
> > It's pretty clear that you're avoiding the question now posed to you
> > over this reflector about a half dozen times. Here it is again:
> >
> > >Recently, Ariel Hendel of Sun has proposed a 10 Gbps rate solution
> > along with a
> > > variable IPG. I consider this to be a reasonable compromise (not
> > my best choice)
> > > to settle this outstanding objective. I have still not heard any
> > good technical
> > > reasons as to why this solution would not work. Would you care to
> > offer clear,
> > > succinct reasons to this effect?
> >
> > I'll indulge your tangential thread anyway.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > Roy Bynum wrote:
> >
> >> Rich,
> >>
> >> The fibre channel standard is predispositioned toward self-owned
> >> fiber facilities.
> >
> > So is Ethernet, currently. In the near future (3-5 years) a very
> > small percentage of Ethernet interfaces may permeate the leased
> > fiber space.
> >
> >> ESCON reliability is very dependent on being able to control
> >> access to, and
> >> potential ad hoc damage to, the fiber facilities by unknown third
> >> parties.
> >
> > Yes. As is Ethernet and Fibre channel because the fiber facilities
> > are "self-owned".
> >
> >> There are no provisions for cross fiber systems transport in fiber
> >> channel.
> >
> > I don't know what this means. Please explain.
> >
> >> The presentation at the last meeting of the Multi-level Analog
> >> Signaling technology recognizes that there was no provision for
> >> detecting inconsistent attenuation at splice points in leased
> >> fiber facilities in GbE.
> >
> > Please elaborate on this point also. I don't recall a MAS slide
> > related to this issue.
> >
> >> There are no provisions for ad hoc damage to fiber facilities by
> >> unknown third parties. OIF has recognized that in order to
> >> transport fibre channel protocols over standard optical networking
> >> systems requires an out of band "digital wrapper". This is not my
> >> "take" on this issue. This is the reflected in the considered
> >> opinion of the entire optical networking services industry.
> >
> > I coming to understand what SONET is and am leaning every day. I
> > believe you need to understand that Ethernet solves most of the same
> > problems that SONET does in a different, simpler, and more cost
> > effective fashion.
> >
> >> Thank you,
> >> Roy Bynum
> >> MCI WorldCom
> >>
> >> Rich Taborek wrote:
> >>
> >> > Roy Bynum wrote:
> >> >
> >> > > Rohit, et al,
> >> > >
> >> > > What is to prevent some unscrupulous vendor from sell a non
> >> WAN/MAN support
> >> > > capable version of 10GbE to someone? Are we to be responsible
> >> for adding to
> >> > > the "caveat emptier" atmosphere of this industry? As it is, a
> >> lot of the
> >> > > sales and marketing people in this industry have the habit of
> >> advertising
> >> > > and sell functionality that they do not have. Are we to
> >> become part of
> >> > > that, by creating a "cheap" version of a protocol that causes
> >> support
> >> > > problems for customers?
> >> >
> >> > Roy,
> >> >
> >> > I'm not aware that Gigabit Ethernet, Fibre Channel, IBM
> >> ESCON(TM), etc. are
> >> > perceived as "cheap" protocols. On the contrary, my perception
> >> is that they are
> >> > very cost-effective protocols, much more so than their WAN
> >> counterparts. I have
> >> > pointed out in a previous note that LAN and SAN links of
> >> significant distance
> >> > (up to 10's of km) are widely deployed in LAN and SAN
> >> applications.
> >> >
> >> > Relative to customer support problems: the Gigabit Ethernet
> >> Physical Layer is
> >> > heavily based upon the Fibre Channel Physical Layer, which in
> >> turn is heavily
> >> > based upon the ESCON Physical and Signaling layers. I have
> >> personally worked on
> >> > all three. Most of the same facilities to provide link fault
> >> detection as well
> >> > as protocols capable of providing fault tolerance and isolation
> >> exist in all
> >> > three. Most mission critical transactions in the USA and a very
> >> large portion
> >> > worldwide still employ ESCON channels for reliable data
> >> transport with 100% data
> >> > integrity and zero downtime. Whatever part of a transaction goes
> >> out on a WAN is
> >> > still guaranteed by protocols at a higher level than the optical
> >> transport. I
> >> > can make a pretty good case for GbE and its follow-on, 10 GbE
> >> being as reliable
> >> > as ESCON and far more cost effective (primarily due to volume).
> >> >
> >> > Just because the LAN and SAN camps approach customer support
> >> from a different
> >> > viewpoint than does the WAN camp, please don't jump to the
> >> conclusion that their
> >> > solution is inferior. It is CLEARLY orders of magnitude more
> >> cost effective. I
> >> > know that I don't fully understand the WAN solutions for
> >> reliable data
> >> > transport, but I am interested in a serious discussion of the
> >> inadequacies of
> >> > Ethernet in meeting customer support objectives.
> >> >
> >> > > The whole reason for the proposal of a 9.584 MAC transfer rate
> >> was to allow
> >> > > the standardization of an optical 10GbE protocol that has the
> >> support
> >> > > functionality that is recognized by the optical networking
> >> industry. There
> >> > > are several people on this reflector that are also
> >> participants in the
> >> > > Optical Interoperability Forum (OIF) that was started by data
> >> communications
> >> > > vendors, among others.
> >> >
> >> > Many very experienced and highly respected 802.3 members have
> >> proposed several
> >> > solutions to 10 vs. 9.58464 MAC/PLS rate objective.
> >> > Recently, Ariel Hendel of Sun has proposed a 10 Gbps rate
> >> solution along with a
> >> > variable IPG. I consider this to be a reasonable compromise (not
> >> my best choice)
> >> > to settle this outstanding objective. I have still not heard any
> >> good technical
> >> > reasons as to why this solution would not work. Would you care
> >> to offer clear,
> >> > succinct reasons to this effect?
> >> >
> >> > P.S. My choice is to use 802.3x flow control between the two
> >> rates and configure
> >> > the network to prevent/minimize packet loss.
> >> >
> >> > > I joined this group for the specific purpose of preventing the
> >> spread of an
> >> > > optical protocol that belonged on copper, not on fiber. I
> >> have no issue
> >> > > with 10.0 MAC transfer rate for copper, it can not be
> >> implemented of 100s
> >> > > and 1,000s of km where the user/customer does not have
> >> viability or ability
> >> > > to support he fiber that he is using. Any protocol that can
> >> be implemented
> >> > > over optical fiber can and will be used over fiber that is
> >> leased, not
> >> > > owned. That means it can not be supported without built in
> >> OAM features in
> >> > > the protocol. Those features are a REQUIREMENT as far as I am
> >> concerned.
> >> >
> >> > My interpretation of the statement above is that you disagree
> >> with all current
> >> > HSSG objectives since those objective do not currently support
> >> any copper
> >> > variant. Is this true?
> >> >
> >> > Ethernet has supported optical PHYs of significant distance at
> >> data rates of 10
> >> > Mbps, 100 Mbps and 10 Gbps. It is only natural that optical PHYs
> >> of similar
> >> > distances are specified for 10 Gigabit Ethernet. In addition,
> >> based on
> >> > Ethernet's expanding markets, it is appropriate to extend
> >> optical PHY distances
> >> > for 10 GbE. This is clearly reflected in the 10 km and 40 km
> >> singlemode fiber
> >> > optical PHY HSSG distance objectives.
> >> >
> >> > SONET OAM features have never even been proposed as a possible
> >> candidate as an
> >> > HSSG objective. I would suggest that if you're interested in
> >> this functionality,
> >> > that you make a formal presentation at the September HSSG
> >> meeting. My best
> >> > judgement is that the functionality of SONET OAM features can
> >> more cost
> >> > effectively be met by standard Ethernet features such as
> >> Management and
> >> > Auto-Negotiation.
> >> >
> >> > > The use of 9.584 transfer rate has been proposed as the most
> >> cost effective
> >> > > and simplest way to provide a base for adding OAM features to
> >> the optical
> >> > > PHYs of 10GbE. It leverages the existing SONET/SDH
> >> technology. It may be
> >> > > that some vendors would like to be able to have their
> >> intellectual property
> >> > > be part of the 10GbE standard. As a data network architect,
> >> designer,
> >> > > implementor, and customer, I would rather see a public domain
> >> standard.
> >> >
> >> > The simplest, most cost effective and open means of providing 10
> >> Gbps Ethernet
> >> > transport is by leveraging all that Ethernet is and doing it ten
> >> times faster.
> >> >
> >> > > Thank you,
> >> > > Roy Bynum
> >> > > MCI WorldCom
> >> > >
> >> > > Rohit Sharma wrote:
> >> > >
> >> > > > I concur entirely.
> >> > > >
> >> > > > "KISS" and make up...
> >> > > >
> >> > > > -rohit
> >> > > > Rohit Sharma
> >> > > > www.opticalnetworks.com
> >> > > >
> >> > > > > -----Original Message-----
> >> > > > > From: Mike Bennett [mailto:mjbennett@xxxxxxx]
> >> > > > > Sent: Thursday, August 05, 1999 12:46 PM
> >> > > > > To: IEEE HSSG
> >> > > > > Subject: Re: Data rate standards vs internal switching
> >> standards
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > I think its time the WAN folks consider a call for
> >> interest
> >> > > > > to do the SONET
> >> > > > > compatible standard separately from the LAN/MAN efforts.
> >> > > > > This would allow
> >> > > > > consensus for a 10 Gbs MAC and we could move on. Devendra
> >>
> >> > > > > Tripathi alluded
> >> > > > > to this yesterday, although to give it an "honorable
> >> mention"
> >> > > > > rather than
> >> > > > > make it standard. I'm curious if others would support a
> >> > > > > separate effort in
> >> > > > > hope that both groups could move forward. I'm not opposed
> >> to a WAN
> >> > > > > standard, but it seems as though there is no end in sight
> >> for
> >> > > > > a compromise,
> >> > > > > that is to choose either a 10 or 9.xyz Gbs data rate.
> >> Some seem to be
> >> > > > > willing to sacrifice the simplicity and low cost of
> >> Ethernet
> >> > > > > to get into
> >> > > > > the WAN market. In my humble opinion as an end user of
> >> > > > > Ethernet equipment,
> >> > > > > if we stray from that which has made Ethernet so
> >> successful to date it
> >> > > > > would negatively affect the future of Ethernet.
> >> > > > >
> >> > > > > Mike Bennett
> >> > > > >
> >> >
> >> > --
> >
> > -------------------------------------------------------------
> > 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
begin: vcard
fn: Martin Nuss
n: Nuss;Martin
org: Bell Labs - Lucent Technologies
adr;dom: 101 Crawfords Corner Rd.;;;Holmdel;NJ;07733-3030;
email;internet: nuss@xxxxxxxxxx
tel;work: 732 949 5358
tel;fax: 732 949 2473
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard