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]<mailto:[email protected]> on behalf of [email protected]<mailto:[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]<mailto:[email protected]>> wrote: On Aug 9, 2016, at 5:55 PM, Lizhong Jin <[email protected]<mailto:[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<mailto:[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]<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 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
