Hi Lizhong, Please see my reply inling.
From: Lizhong Jin [mailto:[email protected]] Sent: Friday, September 06, 2013 3:19 AM To: [email protected]; [email protected]; [email protected]; Lucy yong; [email protected] Subject: Re: [nvo3] comments on draft-sridharan-virtualization-nvgre-03 We can have a better solution to support ECMP. Most switches and routers today support 5 tuple based load balance. Five tuple are IP src/dst addr, tcp|udp src/dst ports, and IP protocol type. draft-yong-tsvwg-gre-in-udp-encap-01 proposes the gre-in-udp encapsulation for GRE encapsulated protocols to be tunneled over IP networks where ECMP exists. This solution supports 16 bits flow entropy, does not require any change on intermediate switches and routers, and applies to any GRE encapsulated protocol. It also gives the ingress end point flexibility to generate the flow entropy without explicitly exposing VSID. I highly recommend NVGRE proposal to adopt this method for ECMP support. [PG] - Thanks, I would take a look at the proposal, however I treat this as another tunneling protocol in addition to three existing ones i.e. NVGRE, VxLAN and STT. What are the specific advantages of this over other protocols? Also many of current generation NIC hardware support offloads for the existing three protocols. Wouldn't using GRE-IN-UDP break those offloads? [Lucy] If NIC hardware support VxLAN which use UDP port for the flow entropy, it should be easy to support gre-in-udp encaps as well. Will be great to see chip vendor comment on this. Please take a look at the gre-in-udp encapsulation proposal (below), welcome comment on it. [PG] Sure, I would take a look at it. [Lizhong] it is not easy to design gre-in-udp from the chip design point of view. The offloading NIC provided is to terminate tunnel. But in gre-in-udp, you have two tunnel layer, then you have to terminate twice for the chip. Then of cource, you will increase the cost, power consumption, and etc. [Lucy] If NIC can terminate UDP tunnel for vxlan and GRE tunnel for NVGRE, it can support gre-in-udp for NVGRE. I don't see the given reasons superior to the benefit gained in the network. My concern is if applying gre-in-udp for nvgre, then why not directly using vxlan? [Lucy] I am glad that you point out this. We also propose vxlan enhancement to add prototype field (see http://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/). These enhancements make nvgre+ and vxlan+ very similar semantics and general to support other overlays. The only difference in between will be that they use different UDP port number and use different bit (3rd bit or 5th ) to indicate the presence of VSID or VNI. In the spirit of IETF and for easy interworking, it will be nice to have one standardized. Given the existing deployment circumstance and chips support both, should IETF compliance and adopt both? This is what the community has to decide. Thanks, Lucy Regards Lizhong Regards, Lucy Here is the draft. The TSVWG will adopt it as WG draft soon. http://datatracker.ietf.org/doc/draft-yong-tsvwg-gre-in-udp-encap/ Regards, Lucy _______________________________________________ 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
