[j-nsp] 2.5 gig SFP modules?
Richard A Steenbergen
ras at e-gerbil.net
Thu May 22 15:13:54 EDT 2008
On Thu, May 22, 2008 at 11:05:08AM -0400, Matthew Crocker wrote:
> Doesn't MRV sell a CDWM 'thingy' that will take two GigE links and
> combine them onto a single 2.5 gb Lambda? You would still need to
> eat up to SFP ports on your routers but you would get 2 gbps over the
> same fiber pairs with EtherChannel bonding.
> Note: 'thingy' is a highly technical term and should be used
Many people sell these, and the technical term is a "mux". This operates
with TDM, not WDM, and are no different than how a SONET mux maps 4 OC12s
into an OC48. Infact most versions of this kind of product (at least the
ones which follow any standards at all) are SONET based, and are simply
transporting the Ethernet frames over a STS-24 channel, of which two are
mapped into an OC48 lambda. Many people make the same thing for 10G, but
you can only get 9xGE out of it due to overhead.
On Thu, May 22, 2008 at 12:38:37AM +0200, Niels Bakker wrote:
> Gigabit Ethernet is cheap because of volume, volume, volume.
> What do you think will happen when the market is splintered like that?
Yes and no. *Ethernet* is cheap because of volume volume volume (and also,
competition competition competition), and thus at this point everyone and
their mother can implement the Ethernet MAC for many gigs of traffic with
$2 worth of commodity hardware. You're confusing the MAC with the PHY, and
the cheapness of a particular data rate within the same class of
technology has very little to do with massive volumes after you reach a
certain minimum threshold, especially when you're not talking about
cutting edge speeds. To put that another way, at this point it isn't going
to cost you significantly more to produce a 2.5GbE component than to
produce a 1GbE component if you have ANY number of customers at all.
By your argument, multirate SFPs which are the same price as 1GbE optics
but do data rates 4x higher shouldn't exist, since they don't have the
massive volume of Ethernet at a single speed driving them. Also by your
own argument, adopting 100GbE over 40GbE is a bad idea since it will
result in a PHY implementation which isn't compatible with any transport
networks and will have significantly reduced volumes for years to come,
thus driving up costs significantly compared to a 40G implementation which
aligns with the actual optical technology.
I think the problem with the logic here comes from Ethernet-centric people
who have only ever seen the changes happen in massive steps with major
techology overhauls accompanied by significant internal protocol changes
(MAC changes, line encoding changes, new autonegotiation methods, etc,
etc). These changes have their place, but there is absolutely no reason
you should be limited to only those. The amount of work required to go
from 1GbE to 2.5GbE should be almost nothing more than bumping the data
rate and then agreeing on what that new number is. Being fixated on the
IEEE's ass slow method of operation (remember these are the same people
who have managed to screw us on an Ethernet jumbo frame standard for years
too, turning another good idea into a practical impossibility) is
remarkably short-sighted, and is how you'll end up screwing yourself with
a shiney new "power of 10" protocol which can't be economically
implemented or used outside the datacenter.
> Do you seriously expect to need big amounts of 2.5 Gbps (over, say, 10
> Gbps) interfaces in your network in three years, when a possible
> industry standard will be there at the very earliest?
Again this is a short-sighted view. I don't have any 2.5G interfaces in my
network today (and infact have many Nx10G interfaces which are becoming
limiting, the same as you), but our two networks are not a representative
sample of the industry as a whole. There are any number of roles which
could be more economically served by a 2.5GbE technology than a 10GbE
technology, and it is absolutely silly to ignore the very real potential
of standardizing that data rate for Ethernet.
But at any rate, we seem to have wandered a bit off-topic, unless Juniper
plans on releasing such a product. :)
Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
More information about the juniper-nsp