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. http://news.thomasnet.com/fullstory/482878 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 <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
