http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-09

Cisco engineers are co-authors of this work.

James Ewing
Cisco Systems

FP, Cisco is fully committed to supporting MPLS across the entire product line, including the Nexus 7000. We are also committed to customer success and therefore provide innovative functionality designed to simplify network operations and optimize network services.

My reference to L3 is not with respect to using an L3 transport to carry the encapsulated traffic, as you state this has been done for years. What OTV does is treat the L2 traffic that is going over the overlay in a way that allows flood/failure control as well as multi-pathing comparable to what is available for Layer 3 traffic. Although OTV handles Ethernet traffic in a different way, Ethernet data streams remain unaltered while large diameter Ethernet limitations are addressed.

OTV is available on Nexus 7000 today, and will be available across the broader Cisco product line in the near future.

FP, Cisco is fully committed to supporting MPLS across the entire product line, including the Nexus 7000. We are also committed to customer success and therefore provide innovative functionality designed to simplify network operations and optimize network services. The “wheel” that is not to be re-invented is the network design, the point is that the functionality can be added seamlessly to the network without requiring a re-design of affected Layer 2 domains or the network backbone.

“This way the server team can move virtual servers and the network team doesn’t have to reinvent the wheel,”

But they are re-inventing the wheel…..

For example, the fact that OTV has a difference in signaling properties on unicast vs. multicast-enabled networks. This functionality seems rather superfluous in that if we *simply* extended a layer 2 network (by MPLS/VPLS/PWE3/dark fiber/etc) we would be able to handle any type of ethernet frames regardless of unicast vs. multicast traffic types. This also begs the question on how MLD/IPv6 multicast is handled by OTV?

Secondly, I would cringe at the concept of using proxy arp between sites as a feature, and yet this is the recommended method in connecting DCs. Verifying true reachability (at a layer 2 basis) is abstracted by networking methods that have caused worlds of pain for the past 15 years.

While MPLS technologies have their faults, when you encapsulate ethernet frames on ingress, you get an unadulterated ethernet frame on the other side. All the basic networking functions that hosts do (ie. arp, broadcast, multicast, etc) work exactly as if the ethernet cable were across the room. The same can not be said for OTV.

Victor, EoMPLS/PWE3/VPLS technologies can be tunneled over IP networks today. Many people are doing this right now because it has worked for 10 years, it’s part of IETF standards that are adopted by the top 5 vendors, and it’s the same constructs that are used in normal networks.

Lastly, OTV, as far as I understand is a NX-OS feature. This means that in order to deploy this I need a NEXUS switch. What about all the 65xx or other devices with MPLS that I already have? What if the other disaster recovery site doesn’t have a nexus 7k, I am out of luck.

While OTV does some sexy things, I just don’t think we are looking at anything that is ground breaking. Been there, done that …