Jesse, It's a question of the benefit of the change versus the cost to modify the hardware. Changing one FPGA or ASIC or reprogramming a network processor is significantly cheaper than redesigning a system architecture.
I certainly agree with and share the frustrations of seeing extensibility built in and then abandoned - over and over again. Regards, Alia On Thu, Aug 11, 2016 at 7:59 PM, Jesse Gross <[email protected]> wrote: > Alia, > > > > This is a self-fulling prophesy. If there are no users of something then, > of course, it will never advance. However, you can’t then use this to argue > that it should not be used because there have been no advancements. > > > > The most common example given in this area is the use of IP options. At > the time that routing was moving to hardware implementations, options were > not widely used and so were not implemented. However, imagine that options > were in common use – do you think that router vendors would have decided > that IP was too difficult to implement and abandoned that market? Or would > we now be accepting that this is a common element of protocols? > > > > It’s hard for me to believe that the capabilities we’re discussing here > are unimplementable. Certainly in the case of NICs, support for Geneve > already exists in shipping products, as I recently pointed out. Switching > ASICs take a bit longer to mature but, again, there have already been > numerous announcements of Geneve support. > > > > Regardless, I don’t believe that protocols should be designed based on the > lowest common denominator. At this point, the goal seems to be unification > and broadest applicability, however, this does not seem to be useful > without focusing on what we are trying to accomplish. As I and others have > said in the past, extensibility is a core need and without it, the protocol > is equally unimplementable. If there is serious debate about what is > required and technically possible then I don’t believe that IETF should > attempt to create a standard. Both of these can only be shown through > evidence of what actually happens. > > > > Jesse > > > > On 8/9/16, 6:28 PM, "nvo3 on behalf of Alia Atlas" <[email protected] > on behalf of [email protected]> wrote: > > > > 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 list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
