> > ** > > 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.
My concern is if applying gre-in-udp for nvgre, then why not directly using vxlan? 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] > https://www.ietf.org/mailman/listinfo/nvo3 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
