Re: Why not have both?
Thanks for the background info.
Henry Ngai
----- Original Message -----
From: Grow, Bob <bob.grow@xxxxxxxxx>
To: <stds-802-3-hssg@xxxxxxxx>
Sent: Friday, September 10, 1999 3:54 PM
Subject: RE: Why not have both?
>
> Henry:
>
> The devices built for 1GbE and called buffered repeaters are a bit
different
> than this 10GbE function. To many, buffered repeaters convey shared
> bandwidth. Most of the presentations to the previous HSSG and 802.3z
> reinforced this notion. This in addition to the other reasons cited make
me
> resist defining a "buffered repeater" for 10GbE.
>
> Bob Grow
> Intel
>
> -----Original Message-----
> From: Henry Ngai [mailto:hngai@xxxxxxxxxxxx]
> Sent: Friday, September 10, 1999 10:57 AM
> To: Ariel Hendel; stds-802-3-hssg@xxxxxxxx
> Subject: Re: Why not have both?
>
>
>
> Ariel,
>
> If you are saying the bridge is a model and not intend to be used in a
real
> application, then that's fine. However, in Howard's mail, that does not
seem
> to be the case.
>
> At 10Gbps, there is a lot of MAC Address updates to a bridge. COST and
> COMPLEXITY does go up with speed. Introducing buffered repeater into the
> picture avoid confusion for people outside of the group when they want to
> implement a device joining two PHY together.
>
> A buffered repeater has NO LEARNING, NO UPDATES, NO STA, NO POTENTIAL
> SECURITY THREATS as seen by ROY. And if we only deal with things that
> exists, why invent, in fact, why even have 802?
>
> Anyway, I cannot make it to YORK, so I will rest my case here.
>
> Henry Ngai
>
> ----- Original Message -----
> From: Ariel Hendel <Ariel.Hendel@xxxxxxxxxxx>
> To: <Ariel.Hendel@xxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>;
> <hngai@xxxxxxxxxxxx>
> Sent: Friday, September 10, 1999 10:31 AM
> Subject: Re: Why not have both?
>
>
> > Henry,
> >
> > I am repeating myself but I think that Howard's use of the term bridge
> > is correct because it relies on an existing concept with the broadest
> > possible abstraction. Adding a buffered repeater to the lexicon is
> > uncertain and unnecessarily reduces the abstraction level.
> >
> > In general something that doesn't exist yet, also doesn't exist period.
> >
> >
> > Ariel
> >
> > >
> > > Ariel,
> > >
> > > Yes, the buffer repeater does not exist yet in the reference model.
But
> the
> > > concept is simple and repeater is a MAC device, and therefore can be
> > > addressed by 802.3 entirely. There is no need to go to any anywhere
else
> to
> > > see if there is need for any additional definition. If we are going to
> > > define two PHYs of similar speed, then defining a buffered repeater
> should
> > > be quite straight forward using XOFF, which is also a MAC function.
> > >
> > > Henry Ngai
> > >
> > > ----- Original Message -----
> > > From: Ariel Hendel <Ariel.Hendel@xxxxxxxxxxx>
> > > To: <stds-802-3-hssg@xxxxxxxx>; <pbottorf@xxxxxxxxxxxxxxxxxx>;
> > > <hngai@xxxxxxxxxxxx>
> > > Sent: Thursday, September 09, 1999 10:55 PM
> > > Subject: Re: Why not have both?
> > >
> > >
> > > > Henry,
> > > >
> > > > The essence of the concept is that there is a MAC on each side, and
> the
> > > > forwarding between LAN and WAN occurs at or above the MAC client
> > > > level.
> > > >
> > > > How the forwarding is accomplished is irrelevant. The "bridge"
> > > > nomenclature used by Howard is therefore appropriate. The "buffered
> > > > repeater" does not really exist elsewhere in the reference model.
> > > >
> > > > Ariel
> > > >
> > > >
> > > > > From: "Henry Ngai" <hngai@xxxxxxxxxxxx>
> > > > > To: "stds-802-3-hssg" <stds-802-3-hssg@xxxxxxxx>, "Paul Bottorff"
> > > <pbottorf@xxxxxxxxxxxxxxxxxx>
> > > > > Subject: Re: Why not have both?
> > > > > Date: Thu, 9 Sep 1999 14:27:25 -0700
> > > > > MIME-Version: 1.0
> > > > > Content-Transfer-Encoding: 7bit
> > > > > X-Priority: 3
> > > > > X-MSMail-Priority: Normal
> > > > > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> > > > > X-Resent-To: Multiple Recipients
> <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> > > > > X-Listname: stds-802-3-hssg
> > > > > X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> > > > > X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
> > > > >
> > > > >
> > > > > Paul,
> > > > >
> > > > > I believe you are correct. I suggest a buffering repeater so we
> don't
> > > have
> > > > > to describe and refer to bridges and routers. A buffering repeater
> also
> > > > > addresses Roy's concern on security. By default, a buffering
> repeater
> > > does
> > > > > not understand any information contained in the packet. It can
also
> be a
> > > > > great signal repeater.
> > > > >
> > > > > Henry
> > > > >
> > > > > ----- Original Message -----
> > > > > From: Paul Bottorff <pbottorf@xxxxxxxxxxxxxxxxxx>
> > > > > To: Henry Ngai <hngai@xxxxxxxxxxxx>; stds-802-3-hssg
> > > > > <stds-802-3-hssg@xxxxxxxx>
> > > > > Sent: Thursday, September 09, 1999 12:26 PM
> > > > > Subject: Re: Why not have both?
> > > > >
> > > > >
> > > > > > Henry:
> > > > > >
> > > > > > Probably the juncture between a LAN PHY and a WAN PHY is going
to
> be a
> > > > > > router/L3-switch rather than a bridge. Howard's model gives us a
> good
> > > > > > architectural reference which could be simplified latter to a
> > > buffering
> > > > > > repeater like or included in a router.
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > > At 10:59 AM 9/9/99 -0700, Henry Ngai wrote:
> > > > > > >
> > > > > > >Howard,
> > > > > > >
> > > > > > >I believe you are right in shooting for two different PHYs.
> However,
> > > I do
> > > > > > >not think bridge is a good way to join the two MACs and PHY
> together.
> > > > > Unless
> > > > > > >we impose the implementation of a bridge with all its overhead
on
> the
> > > WAN
> > > > > > >link. A better approach to explain the simplicity of such a
> device
> > > may be
> > > > > a
> > > > > > >buffering repeater.
> > > > > > >
> > > > > > >As a buffering repeater, there is no need to worry about how
STA
> > > works in
> > > > > > >this environment, nor is there need for bridge MIBs.
> > > > > > >
> > > > > > >Rate differences, in case of over 95% utilization at the 10G
side
> of
> > > the
> > > > > > >network, can be handled by XOFF protocols.
> > > > > > >
> > > > > > >Henry Ngai
> > > > > > >
> > > > > > >
> > > > > > >----- Original Message -----
> > > > > > >From: Howard Frazier <hfrazier@xxxxxxxxx>
> > > > > > >To: <stds-802-3-hssg@xxxxxxxx>
> > > > > > >Sent: Wednesday, September 08, 1999 5:51 PM
> > > > > > >Subject: Why not have both?
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >> >From the various statements posted to this reflector over
the
> past
> > > > > > >> few months, it has become obvious to me that the LAN and WAN
> > > > > > >> markets have different needs when it comes to the physical
> layer
> > > > > > >> of a network interface. I would also say that it is apparent
> that
> > > > > > >> the HSSG is at an impasse. I doubt very much that either the
> > > > > > >> LAN devotees or the WAN devotees will be able to
> > > > > > >> persuade their opposite numbers to abandon their well thought
> out
> > > > > > >> and closely held beliefs and settle on a single Physical
Layer
> > > > > > >> definition that will serve both markets.
> > > > > > >>
> > > > > > >> Therefore, I encourage the HSSG to consider the development
of
> > > > > > >> two distinct PHYs for 10 Gigabit Ethernet. Let's call one
the
> > > > > > >> LAN PHY, and the other, the WAN PHY. Each of these
> specifications
> > > > > would
> > > > > > >be optimized for the intended application.
> > > > > > >>
> > > > > > >> As others have already stated, it is possible to build a
> relatively
> > > > > > >> simple, low cost, low complexity device that will bridge
these
> > > > > > >> interfaces together. A layer diagram of such a device is
shown
> in
> > > > > > >> the attached PDF file.
> > > > > > >>
> > > > > > >> Referring to the diagram, on the left side, we have a cloud
> labled
> > > > > > >> "LAN infrastructure". This is made up of the switches,
> routers,
> > > > > > >> hubs, NICs, firewalls, gateways, servers, desktops, etc, etc,
> > > > > > >> that communicate via Ethernet. On the right side, we have a
> > > > > > >> cloud labled "WAN infrastructure". This is made up of the
> > > > > > >> transponders, multiplexors, regenerators, amplifiers,
etc,etc,
> > > > > > >> that conform to SONET specifications.
> > > > > > >>
> > > > > > >> In between these two clouds, we have a bridge. In the
context
> > > > > > >> of 802.3 standards, this is an 802.1D bridge, but in
practice,
> > > > > > >> it could have more or less functionality than required by
> 802.1D.
> > > > > > >> The primary purpose of this device is to hide all of the
> details
> > > > > > >> of the underlying LAN and WAN PHYs from each other. The
> > > > > > >> PHYs can use completely different signaling methods, they can
> > > > > > >> use different physical media, they can run at different
rates.
> > > > > > >> They can also have different management attributes.
> > > > > > >>
> > > > > > >> I assert that the cost of such a device is dominated by the
> cost
> > > > > > >> of the PMD (the optical components) associated with the
> > > > > > >> WAN interface. I can't throw dollar figures around, but I
can
> > > > > > >> state with conviction that the sum of the costs for the LAN
> PMD,
> > > > > > >> the LAN PHY, the LAN MAC, the Bridge, any associated memory,
> > > > > > >> any associated microprocessor, the WAN MAC, and the WAN
> > > > > > >> PHY, and associated management, is about 1/25th of the cost
> > > > > > >> of the WAN PMD and its associated clock oscillator. That's
> > > > > > >> right. Relatively speaking, the WAN optics cost about 25
times
> > > > > > >> as much as the rest of the components in the box combined.
> > > > > > >>
> > > > > > >> That tells me that such a device will definitely not be a
> barrier
> > > > > > >> to the use of 10 Gigabit Ethernet in the WAN, and it might
even
> > > > > > >> be considered an "enabler", because it can connect to the LAN
> > > > > > >> infrastructure just about anywhere you wish. Of course,
since
> > > > > > >> I am suggesting that we specify a WAN PHY as well as a LAN
> > > > > > >> PHY, it is possible to build an interface for an "Enterprise"
> LAN
> > > > > > >> switch that provides a WAN PHY and PMD, and maybe this
> > > > > > >> will happen. The "Two PHY" approach allows inovation and
> > > > > > >> optimization to keep pace with technology development, and
> > > > > > >> the needs of the market.
> > > > > > >>
> > > > > > >> It will also let us get going in the HSSG, and put some of
the
> > > > > > >> arguments behind us. To that end, I suggest that we:
> > > > > > >>
> > > > > > >> 1) Adopt an objective to specify a PHY optimized for LAN
> > > > > > >> applications.
> > > > > > >>
> > > > > > >> 2) Adopt an objective to specify a PHY optimized for WAN
> > > applications.
> > > > > > >>
> > > > > > >> 3) Settle the "speed" objective by stating that the MAC/PLS
> > > > > > >> interface always runs at 10.0000 Gb/s.
> > > > > > >>
> > > > > > >> This speed will work with either PHY. For various reasons,
> > > > > > >> the WAN PHY will require at least a packet's worth of
buffering
> > > > > > >> in each direction. If you have to have the buffer, you might
> > > > > > >> as well use it to match the 10.0000 Gb/s MAC/PLS rate to
> > > > > > >> the 9.95328 baud rate on the WAN medium.
> > > > > > >>
> > > > > > >> 4) Agree that a pacing mechanism of some sort can be employed
> > > > > > >> if necessary to throttle the MAC's transmit data rate down to
a
> > > > > > >> rate which is compatible with the payload rate of a WAN PHY.
> > > > > > >>
> > > > > > >> With a packet buffer in the PHY, this pacing mechanism can
> > > > > > >> operate on a packet by packet basis.
> > > > > > >>
> > > > > > >> Note: If you were to design an integrated MAC and WAN PHY,
> > > > > > >> you could get rid of the buffer and the pacing mechanism.
> > > > > > >>
> > > > > > >> 5) Agree that the two PHYs need to be individually justified
in
> > > > > > >> the "5 Criteria". I am not suggesting that two PHYs means
two
> > > > > > >> standards projects (i.e. two PARs), but I do think that we
need
> > > > > > >> to answer the 5 Criteria for both PHYs, so that the rest of
the
> > > > > > >> world understands why we are doing this. I think it will be
> > > > > > >> easier to come up with words which justify the two PHYs
> > > > > > >> individually than it would be to agree to one set of words
that
> > > > > > >> embraces both PHYs.
> > > > > > >>
> > > > > > >> Please give this suggestion some serious thought.
> > > > > > >>
> > > > > > >> Howard Frazier
> > > > > > >> Cisco Systems, Inc.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
>
>---------------------------------------------------------------------------
> > > > > -
> > > > > > >----
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > Paul A. Bottorff, Director Switching Architecture
> > > > > > Enterprise Solutions Technology Center
> > > > > > Nortel Networks, Inc.
> > > > > > 4401 Great America Parkway
> > > > > > Santa Clara, CA 95052-8185
> > > > > > Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
> > > > > > email: pbottorf@xxxxxxxxxxxxxxxxxx
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>