Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Nov 2015 09:44:38 +0900

On Sun, Nov 1, 2015 at 1:12 PM, Jesse Gross <[email-masked]> wrote:
> Sure, probably all of the hardware implementations have some limits on their
> ability to handle the full breadth of Geneve options. Geneve was
> intentionally designed to be very future proof and support limits beyond
> what I would realistically expect people to implement/use in the near
> future. The more interesting question is whether it is possible to support a
> useful set for what we need today. Unfortunately, I can’t really give
> specifics for different implementations (in the cases that I know) but let
> me try to make some generalizations and you can follow up with individual
> vendors if you need more details.
>
It would great if TLV processing in the HW data path is now a solved
problem and we can soon start productively defining and using TLVs in
various protocols with worry (I would like to at least use IPv6
extensions headers for instance). But, AFAIK that is not the current
reality. Maybe some HW designers on this alias can chime in...

Tom

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 2 Nov 2015 02:16:31 +0000

Hi all,

Prior to jumpping into the competition of designing various data encapsulation options for flexibility purposes, should we firstly make sure what flexibility is really needed. I have not seen any detailed disscussion in the nvo3 PS and requirement drafts and even in the mailing-list.

Best regards,

Xiaohu

________________________________
发件人: nvo3 [[email-masked]] 代表 Diego Garcia del Rio [[email-masked]]
发送时间: 2015年11月1日 10:40
收件人: Jesse Gross
抄送: Manish Kumar (manishkr); Tom Herbert; [email-masked]; Lucy yong; Pankaj Garg; Dino Farinacci
主题: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

Thanks for the references. But out of all the switching asics, which are arguably the most constrained in terms parsing flexibility and need for performance, how many support arbitrary tlvs push/pop? Geneve in its most basic form without options looks very similar to vxlan and thus I'm not surprised we can see several of the products claiming support for it. But when we start adding arbitrary protocol types and variable options I'm not so sure that those implementations can claim full support. Even for the nics and all the offloads, it comes a moment where the parsing engines can't look deep enough into the packet and then we have a problem.

I think there is a reason why there is quite some pushback from the hardware side against variable length options.

My two cents,
Diego

On Oct 30, 2015, at 21:29, Jesse Gross <[email-masked]<mailto:[email-masked]>> wrote:

From: Tom Herbert
Date: Saturday, October 31, 2015 at 9:40 AM
To: Jesse Gross
Cc: Pankaj Garg, "[email-masked]<mailto:[email-masked]>", "Manish Kumar (manishkr)", Dino Farinacci, Lucy yong
Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

To follow up on Pankaj’s mention of ecosystem support, one comment about the
viability of TLVs is that whether they are a useful extension mechanism is
mostly based on the implementer’s perception. If they are seen as an add-on
that is not really core functionality (as in IPv4 and IPv6), then sure,
people won’t bother to support them. However, in the case of Geneve, they
are obviously the major goal of the protocol and they are being implemented,
in both software and hardware.

Jesse,

Your point that TLVs are major goal of Geneve would be much stronger
if you could reference defined TLVs that are critical to the protocol
function. Maybe I'm missing something, but I can't find any defined
TLVs for Geneve on the web at all.

Here is an example from OVN:
https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml#L1014

OVN is actually a pretty useful reference in general because it is an open source network virtualization implementation that is using Geneve as its preferred encapsulation.

And here is a list of implementations of Geneve that I am aware of, from my presentation at the meeting in Prague plus a few additional ones that I became aware of since then. We don’t really need to speculate what people might do, given that there are a number of implementations already from different vendors. (This is all public.):

Controller:
Open Virtual Networking (OVN)

Software Endpoint:
Open vSwitch
Linux

Debugging Tool:
Wireshark
tcpdump
libpcap

NIC:
Intel XL710
Mellanox ConnectX-4
Broadcom NetXtreme C-Series
QLogic 578xx
Netronome NFP-6xxx

Switching ASIC:
Broadcom Trident 2+/DNX
Cavium XPliant
Mellanox Spectrum
Intel Red Rock Canyon
Centec GoldenGate
Marvell Prestera
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3