https://www.cs.purdue.edu/homes/kompella/publications/infocom13.pdf
On Wed, Mar 4, 2015 at 2:55 PM, Larry Kreeger (kreeger) <kree...@cisco.com> wrote: > Hi Sunil, > > It seems like your question would be more appropriate for the NVO3 mailer > than the SFC one (so I added NVO3). > > Note that the ideas covered in draft-chen-nvo3-load-banlancing do not seem > to be part of the NVO3 charter, nor is it part of the NVO3 problem > statement, nor has it been discussed on the NVO3 mailer to my knowledge. I > did take a look at the draft, and I am skeptical of its cost/benefit for > implementation. > Yes, it seems like a lot of additional protocol machinery. If we didn't have to worry about OOO packets then simply modulating the UDP source port will allow packets in the same flow to go over different ECMP paths. In fact, we are seeing renewed interested in this for packet spraying in DCs. UDP encap is compelling because of the ability source route via the source port. https://www.cs.purdue.edu/homes/kompella/publications/infocom13.pdf Tom > - Larry > > From: Sunil Vallamkonda <suni...@f5.com> > Date: Wednesday, March 4, 2015 2:30 PM > To: "s...@ietf.org" <s...@ietf.org> > Subject: [sfc] VxLAN-gpe vs nvo3 > > Per http://tools.ietf.org/html/draft-quinn-sfc-nsh-07 > > Section 11.2, VxLAN-gpe can be an encapsulation. > > However, how does the VxLAN-gpe header co-exist with overlapping VxLAN > header modification by nvo3: > > https://datatracker.ietf.org/doc/draft-chen-nvo3-load-banlancing/ > > > > Sunil > > > > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
