[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  
> sparingly...

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 mailing list