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 protected]] 代表 Diego Garcia del Rio [[email protected]] 发送时间: 2015年11月1日 10:40 收件人: Jesse Gross 抄送: Manish Kumar (manishkr); Tom Herbert; [email protected]; 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 protected]<mailto:[email protected]>> wrote: From: Tom Herbert Date: Saturday, October 31, 2015 at 9:40 AM To: Jesse Gross Cc: Pankaj Garg, "[email protected]<mailto:[email protected]>", "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 protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
