VXLAN and NVGRE – more information

There’s so much great material being written on VXLAN and NVGRE that I decided to write a separate post listing the best of it (if you still can’t decide whether you should care about VXLAN, register for my Introduction to Virtual Networking webinar).

Omar Sultan published a three-part series on Cisco’s Data Center blog: In-depth VXLAN description, Comparison with OTV, MAC-in-GRE and LISP and More FAQ (including relationship between VN-Tag and VXLAN). The information in these posts is pretty much spot-on and accurate.

Denton Gentry @ Coding Relic wrote another great series: Introduction, Encapsulation and Learning, and Transition and Gateways. He also did a deep dive (as far as one could go given the current fuzzy state of the pseudo-draft) on NVGRE (I simply couldn’t be bothered after figuring out how much of the real stuff is still missing).

Martin Casado eloquently pointed to the elephant in the room – lack of control plane – and suggested (what else) OpenFlow as the solution (it’s also nice to see you can get bonus points by not figuring out what needs to be done).

Last but definitely not least, there are two masterpieces from vendors marketing departments to make you laugh: HP claims VXLAN uses more power than EVB (no wonder, as the latter probably only works in PowerPoint) while Dell promises to support VXLAN, NVGRE, OpenFlow and unicorn tears.

Vishwas Manral rightfully pointed out that he does not work in HP marketing. Fixed the last paragraph.

10 comments:

  1. That just shows Dells dedication to innovation. I don't see unicorn tears anywhere on Cisco, Juniper, or HPs road map. I think we can all agree that "network virtualization" and the data center of the future will NOT happen unless everyone gets on board with the UTSDN (Unicorn Tears Software Defined Networking) standard.

    ReplyDelete
  2. Hi Ivan,

    I got pointed to this piece you have written.

    You have talked about the HP VXLAN piece that I have written above being from marketing departments. You may first want to know I am not into marketing but engineering. I have given technical points to the discussion from where I see it, and if you see the feeds on twitter, discussions on IETF and linkedin you would know what I am talking about.

    I would think you seem to be marketing your blog with a lot os sensationalism without even reading the details of the blog or the comments posted their in (or even reading the title of the author and declaring the team he belongs to). If you really think you have some technical knowledge let us have a technical discussion on the ARMD list where all these technologies have been discussed. http://www.ietf.org/mail-archive/web/armd/current/maillist.html

    Thanks,
    Vishwas

    ReplyDelete
  3. BTW Ivan you may notice on the ARMD list I pointed to already has most of the discussions on NVGRE and VXLAN much before the blog you point to got published. Have a look at http://www.ietf.org/mail-archive/web/armd/current/msg00250.html and following discussions.

    BTW I would love to hear if you still think I am in the marketing department. :)

    ReplyDelete
  4. To be honest, I'm so sick and tired of vendors' positioning games that I made a wrong assumption. Fixed.

    You might be surprised to learn that I actually agree with the technical details of your argument, but find it irrelevant, because

    (A) we yet have to see a shipping EVB products
    (B) VXLAN, NVGRE and OpenFlow/GRE solutions bypass the VLAN limitations and many of the bridging reliability/scalability issues.

    I also hope you formed your opinion of my blog and my writing style by reading more than a single paragraph that you found offending. If, after reading my EVB/VXLAN/virtualization/data center-related posts you still think I'm a sensationalist with no clue what I'm writing about, so be it.

    Kind regards,
    Ivan

    ReplyDelete
  5. Hi Ivan,

    I dug in deeper into other blog posts and I agree I found some good technical discussions on the same. It is also great we agree technically on things.

    First to answer your questions:

    (A) Not yet shiping product does not necessarily mean it is vaporware.
    (B) Note the VLAN limitations (<4094) do not necessarily need a seperate tag (though it may be a simpler solution). Also note we need some mapping tables to map into instances, if we add more intelligence in the mapping tables we can get more instances in the cloud though not on a particular switch (think of 2 devices that never talk to each other - we do not need seperation at the higher layer between them). Like I mentioned engineering approaches have their tradeoffs and that is what I have been trying to bring out.

    With that said you have to note that the blog is not an announcement of a product (where you can announce it as marketingl), but about comparison of technologies.

    Thanks,
    Vishwas

    ReplyDelete
  6. Let's start with (B): If you read the EVB description here: http://blog.ioshints.info/2011/05/edge-virtual-bridging-evb-8021qbg-eases.html, you'll notice I'm well-aware of VDP capabilities and the GroupID field in the VDP messages ... and I'm actually promoting EVB as the best layer-2 hypervisor-to-switch integration technology that allows you to grow beyond VLAN limits.

    What I was actually referring to were the fundamental limitations of bridging (example: flooding of unicasts). They might be addressable with SPB/TRILL combined with PBB, but it's way simpler to use existing IP transport than to introduce so many new technologies in your network. See also this post: http://blog.ioshints.info/2011/05/complexity-belongs-to-network-edge.html

    As for (A), you'll see me change my mind when I see a hypervisor switch supporting VDP. I've heard too many (so far empty) "we will support X once it's ratified" promises from a certain vendor that we both know only too well.

    ReplyDelete
  7. Hey Ivan,

    Here is a way to achieve multi-tenancy (with greater than > 4094), using the same UDP/ GRE encapsulation without any propritory extensions and using an IP network.

    http://www.ietf.org/mail-archive/web/armd/current/msg00287.html

    You can assume the text is written solely for your blog. :)

    Thanks,
    Vishwas

    ReplyDelete
  8. Have a look at the thread I have pointed, you get it all with a few limitations. :) Let me know your views on the same.

    ReplyDelete
  9. You still have to coordinate VLAN numbers with the virtualization platform. Could be made to work, but would require extensive orchestration like the various Carrier Ethernet-related ideas. Separating virtualization platforms and transport networks with IP is a much cleaner approach.

    Anyhow, I've sent you a LinkedIn invite, let's continue the discussion with email.

    ReplyDelete
  10. You still have to coordinate VLAN numbers with the virtualization platform. Could be made to work, but would require extensive orchestration like the various Carrier Ethernet-related ideas. Separating virtualization platforms and transport networks with IP is a much cleaner approach.

    Anyhow, I've sent you a LinkedIn invite, let's continue the discussion with email.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.