FWIW, I don't think we should be designing ANY protocols in the IETF based solely on the limitations of existing hardware. By the time the doc is issued, this hardware is very likely to be in a recycling bin.
Joe On 8/8/2016 12:43 AM, Lizhong Jin wrote: > Hi, > With my design experience of NIC and Switch, I prefer VXLAN-GPE. I > have the same concern of HW complicated logic from Fabio, and > additional concern to GENEVE and GUE is its long size of header. > 1. GENEVE: 256+8=262Bytes > 2. GUE: 128+4=132Bytes > In many current switch and NIC design, the parser buffer size is still > 128Bytes, and some NIC/DMA has 256Bytes buffer. This is workable because: > 1. IPv4 options is not widely used. > 2. IPv6 extension header only support with limited number. > But if adding GENEVE/GUE header, the minimum size of buffer is > 256Bytes, or even 512Bytes. Then the question is, does the hardware > need to process these Variable Length Options/Optional Fields/Private > Data. If not, then it is not reasonable to force the hardware to > increase the cost, but gain little. > > Lizhong > > > > > ---------- Forwarded message ---------- > From: Alia Atlas <[email protected] <mailto:[email protected]>> > To: NVO3 <[email protected] <mailto:[email protected]>> > Cc: "Bocci, Matthew (Nokia - GB)" <[email protected] > <mailto:[email protected]>> > Date: Fri, 29 Jul 2016 11:13:00 -0400 > Subject: Re: [nvo3] Consensus call on encap proposals > I'd like to have people focus on the key point of this thread. > > Are there serious technical objections (and specifically what are > they) to moving forward with VXLAN-GPE as the standards-track > protocol? > > Are there serious technical objections (and specifically what are > they) to moving forward with GENEVE as the standards-track protocol? > > Are there serious technical objections (and specifically what are > they) to moving forward with GUE as the standards-track protocol? > > We need to capture any relevant objections. So far, there's been > some discussion on extensibility - with Tom Herbert providing > concrete concerns. > > I have concluded that almost all the authors would prefer to have > no standards track solution if they can't guarantee that theirs is > that standard. > > I do hear concerns about whether a decision will be too late. I > think that a decision can only be helpful. It goes back to when > is the best time to plant a tree - with the answer of 20 years ago > or now. > > Regards, > Alia > > > On Fri, Jul 29, 2016 at 4:34 AM, Naoki Matsuhira > <[email protected] <mailto:[email protected]>> wrote: > > > > On 2016/07/21 23:56, Bocci, Matthew (Nokia - GB) wrote: > > WG > > There was a discussion in the NVO3 WG meeting in Berlin > following strong advice from our Area Director that we > need to come to a consensus on converging on a common > encapsulation. Two sets of questions were asked: > (1) Should the WG move forward with one standards track encap? > (2) For a given encap, do you have significant technical > objections? > > > I want to inform to this mailing list that I proposed ME6E-FP > and ME6E-PR at the yokohama meeting. I also have proposal > M46E-FP and M46E-PR (past called SA46T). > > These encapsulation technologies are based on address mapping. > ME6E use IPv6 address which mapping MAC address, and M46E use > IPv6 address which mapping IPv4 address. > > I understand too many encapsulation technologies, however > these my proposal are simple, and may contribute to the Internet. > > I believe address mapping approach is unique, so I want to > propose again. > > sorry not the answer to the question. > > Naoki Matsuhira > > > _______________________________________________ > nvo3 mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nvo3 > <https://www.ietf.org/mailman/listinfo/nvo3> > > > > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
