> On Aug 9, 2016, at 5:55 PM, Lizhong Jin <lizho....@gmail.com> 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 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 <akat...@gmail.com> >>> To: NVO3 <nvo3@ietf.org> >>> Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com> >>> 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 >>>> <matsuh...@jp.fujitsu.com> 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 >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> 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
