Joe, In the past 15+ years, I haven't seen this limitation going away. It is expensive to pass the whole packet through the packet forwarding logic. To remove it would require significantly faster I/O to the packet forwarding logic, instead of being able to stream most of the packet to memory to be reunited with the packet header after the lookup logic.
Given that this is frequently a basic attribute of a system's architecture, expecting it to change drastically to handle an encapsulation without stunning technical advantage is rather unlikely. If this concern is what is behind the "too extensible" comments, then it is a significant technical objection. This isn't a question of it being simply slightly harder to implement or having different opinions on the trade-offs of different types of extensibility. It is one thing to have to reprogram an FPGA, write new micro-code for a network processor or even respin an ASIC. It is another thing to need to change the basic architecture of a system. To my mind, this isn't something that should be dismissed with a "oh, systems will just get better". This is and has been a common architecture approach taken as routers have become hardware based. That doesn't mean that everyone with every system has the issue. The question is for significant technical objections - and the encapsulation not being implementable on many existing architectures is highly relevant. I appreciate Lizhong being so clear and direct about the issue. Regards, Alia On Tue, Aug 9, 2016 at 9:03 PM, Joe Touch <[email protected]> wrote: > > > On Aug 9, 2016, at 5:55 PM, Lizhong Jin <[email protected]> wrote: > > Right, but currently we are discussing which solution is better? > > > Yes, but... > > Then it is valuable to consider the existing/potential hardware > implementation, and get pros/cons. > > > Future yes. Existing, no. We those deployed devices will be gone and we'll > be left with their limitations. > > Standards should drive the future and should not be hobbled by the past. > > Joe > > > > Regards > Lizhong > On 08/09/2016 23:56, Joe Touch <[email protected]> wrote: > > 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]> >> To: NVO3 <[email protected]> >> Cc: "Bocci, Matthew (Nokia - GB)" <[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]> 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] >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> >> >> > > > _______________________________________________ > nvo3 mailing [email protected]https://www.ietf.org/mailman/listinfo/nvo3 > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
