Thanks, Sailboat -- good input. Yeah, I'm speculating a lot on what Lightwire can do, so you could be right about them not being ready for the line side yet. I'd be really surprised if they're not being used on the client side here, though.
acohn: > Peter seems to really hate MPLS .... They should take the DWDM bit, and replace the IPv6 bit with MPLS.
Nice analysis of the IPv6/MPLS tradeoff. Thanks.
On the surface, it sounds like they went with IPv6 because of the extra uses they put the address space to. But I guess they give up some of those MPLS capabilities in doing so -- the lookups being cheaper, for instance.
The article speculated that the Lightwire acquisition was the technology source behind the new 100g ports. NOT.
the lightwire technology, while interesting, is not suitable for line side optics. And, it is still only a 10G x several wavelengths. Useful in shorter reach applications like enterprise and data centers (so the Data Center play from Cisco which is part of this deal could be using Lightwire for rack to rack interconnect for instance). But line side optics from lightwire? nope, not there yet,.... not for a good while to come.
far more likely is the fruition of the development work that has been going on at the old CoreOptics over the last year or so. The CoreO technology is perfectly suited to helping reduce form factor for the 100G line side and allow direct active DWDM optics onto the line cards for the routers.
Probably they have 2 versions of interfaces that are both "100g"... one that is only 10 x 10G from lighwire for shorter reaches and one that is truly 100G DWDM with tunable optics for line side.
I would think that this network is using a new generation of products that aren't announced yet. Think about electro-optical devices that are carrying the backbone instead of the conventional "routers & DWDMs".
Prediction: Electro-optical networking in the physical layer will be a trend for 2013.
Sprint by refusing MPLS was married to Cisco, delivering funky features late (compared to competitors running MPLS) such as 'MPLS VPN over IP tunnels' (which has nothing to do with MPLS, config-wise it looks same, but tunneling is done by IPv4 not MPLS).
Certainly you can tunnel L3 VPN and L2 VPN over IPv6 or MPLS. You can do FRR, LFA over IPV6 just the same.
But you absolutely shouldn't. MPLS lookup is cheaper than IPv6 lookup. MPLS functionality is standardizes, interoperates and ships. MPLS is 32bits, IPV6 is 128bits, causing higher MTU use. It would make sense, if you could extract some value from it, but you cannot. Tunneling is tunneling.
DWDM to router is otoh is solid idea in many deployments, but certainly not novel idea, it's been done for decades. And probably by this agenda, people managed to fool DTAG into believing the whole show is OPEX/CAPEX cheaper than their own design. They should take the DWDM bit, and replace the IPv6 bit with MPLS.
> Note that it seems they're using the IP address instead of the IPv6 option space (which is nicely designed, unlike today's IPv4 or TCP option space). I can't speak towards QoS (or any real details on the implementations I'm using), but when you control one or both ends of the IPv6 connection it's quite nice to use the extra "whitespace" for encoding other data....
So much more to IPv6 than just bigger addresses. Thanks, JD.
If they are using passive splitters, etc. it sounds like they are launching the waves from the router. The issue with that right now is the density for IPoDWM is terrible. The CRS is at 1x100G per slot versus 4x100G for current transponder based setups. Other vendors like Juniper and ALU aren't even bothering with it until the packaging makes sense. Unless they are just mapping a 1:1 transponder port to a wavelength and then into a passive setup. Seems like it would be difficult to manage in some situations.
Note that it seems they're using the IP address instead of the IPv6 option space (which is nicely designed, unlike today's IPv4 or TCP option space). I can't speak towards QoS (or any real details on the implementations I'm using), but when you control one or both ends of the IPv6 connection it's quite nice to use the extra "whitespace" for encoding other data. This breaks down if you're encapsulating actual IPv6 clients or if you don't own either end of the IPv6 address, but I can certainly see that routing may need to become a bit more complicated than just most-significant-bit-first routing. Dealing with subnets that aren't just a bunch of ones followed by a bunch of zeros adds a lot of power to IPv6 since you could pull out that bits 91-95 are to determine QoS, 96-100 are to fine tune local load balancing, 101-128 are for content identitication, etc.
The blogs and comments are the opinions only of the writers and do not reflect the views of Light Reading. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
