Re: [nvo3] Consensus call on encap proposals

On Thu, Jul 21, 2016 at 7:56 AM, 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

Re: [nvo3] Consensus call on encap proposals

On 8/12/2016 1:05 PM, Tom Herbert wrote: >> The tide there is turning; even the OPS groups are starting to admit >> > that we can't simply deprecate IP options, but we can do things to >> > encourage their more widespread support (e.g., limit the chain, etc.). >> > > I hope you're right and

Re: [nvo3] Consensus call on encap proposals

On Fri, Aug 12, 2016 at 10:59 AM, Joe Touch wrote: > > > On 8/12/2016 10:54 AM, Tom Herbert wrote: >> On Fri, Aug 12, 2016 at 10:21 AM, Joe Touch wrote: >>> >>> On 8/11/2016 4:59 PM, Jesse Gross wrote: >>> >>> The most common example given in this area is the use of

Re: [nvo3] Consensus call on encap proposals

On 8/12/2016 10:54 AM, Tom Herbert wrote: > On Fri, Aug 12, 2016 at 10:21 AM, Joe Touch wrote: >> >> On 8/11/2016 4:59 PM, Jesse Gross wrote: >> >> The most common example given in this area is the use of IP options. At the >> time that routing was moving to hardware

Re: [nvo3] Consensus call on encap proposals

On Fri, Aug 12, 2016 at 10:21 AM, Joe Touch wrote: > > > On 8/11/2016 4:59 PM, Jesse Gross wrote: > > 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

Re: [nvo3] Consensus call on encap proposals

On 8/11/2016 4:59 PM, Jesse Gross wrote: > 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

Re: [nvo3] Consensus call on encap proposals

On Thu, Aug 11, 2016 at 5:20 PM, Alia Atlas wrote: > 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

Re: [nvo3] Consensus call on encap proposals

62Bytes > > 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 nu

Re: [nvo3] Consensus call on encap proposals

e. Lizhong -- Forwarded message -- From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>> To: NVO3 <nvo3@ietf.org<mailto:nvo3@ietf.org>> Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>&g

Re: [nvo3] Consensus call on encap proposals

Some basic notes below... On 8/11/2016 1:57 AM, Patrick Frejborg wrote: > Hi Joe, > > think we are on the same page - your experience regarding OAM with > X-bone seems to match what I think on how it should be used in NVO3. > And if that is the case, then we have a need of a control protocol >

Re: [nvo3] Consensus call on encap proposals

Hi Joe, think we are on the same page - your experience regarding OAM with X-bone seems to match what I think on how it should be used in NVO3. And if that is the case, then we have a need of a control protocol between the VTEPs, here we can then add different extensions and keep the overlay

Re: [nvo3] Consensus call on encap proposals

On Tue, Aug 9, 2016 at 7:41 PM, Alia Atlas wrote: > Tom, > > On Tue, Aug 9, 2016 at 10:27 PM, Tom Herbert wrote: >> >> On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas wrote: >> > Joe, >> > >> > On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch

Re: [nvo3] Consensus call on encap proposals

On 8/10/2016 10:47 AM, Patrick Frejborg wrote: > Hi Joe, > > I have not stated that we should use RTCP/SIP as such, as you said > "using SIP as anything but general inspiration is useful here" is > totally correct. My misinderstanding; glad we're on the same page. > The VTEPs will more and

Re: [nvo3] Consensus call on encap proposals

gt; 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 >>

Re: [nvo3] Consensus call on encap proposals

On 8/9/2016 11:19 PM, Patrick Frejborg wrote: > Hi Joe, > > I should have used Overlay Controller Schemes instead of OCP, all > current overlay solution do have some "signalling" mechanisms to setup > and tear down the tunnels, a bunch of protocols. Probably you could > make extensions to SIP as

Re: [nvo3] Consensus call on encap proposals

Hi Joe, I should have used Overlay Controller Schemes instead of OCP, all current overlay solution do have some "signalling" mechanisms to setup and tear down the tunnels, a bunch of protocols. Probably you could make extensions to SIP as well and have that as an Overlay Controller Scheme (OCS),

Re: [nvo3] Consensus call on encap proposals

Tom, On Tue, Aug 9, 2016 at 10:27 PM, Tom Herbert wrote: > On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas wrote: > > Joe, > > > > On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch wrote: > >> > >> > >> > >> On 8/9/2016 6:28 PM, Alia Atlas wrote: >

Re: [nvo3] Consensus call on encap proposals

On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas wrote: > Joe, > > On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch wrote: >> >> >> >> On 8/9/2016 6:28 PM, Alia Atlas wrote: >> > Joe, >> > >> > In the past 15+ years, I haven't seen this limitation going away. >> >> If you

Re: [nvo3] Consensus call on encap proposals

Joe, On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch wrote: > > > On 8/9/2016 6:28 PM, Alia Atlas wrote: > > Joe, > > > > In the past 15+ years, I haven't seen this limitation going away. > > If you want to base a limitation on a prediction of future hardware, > then do that. > > But

Re: [nvo3] Consensus call on encap proposals

gt;> >> >> >>> >>> -- Forwarded message -- >>> From: Alia Atlas <akat...@gmail.com> >>> To: NVO3 <nvo3@ietf.org> >>> Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.c

Re: [nvo3] Consensus call on encap proposals

Date: Fri, 29 Jul 2016 11:13:00 -0400 Subject: Re: [nvo3] Consensus call on encap proposals I'd like to have

Re: [nvo3] Consensus call on encap proposals

Hi, Patrick, On 8/9/2016 1:02 PM, Patrick Frejborg wrote: > Whoa! > Will indeed have a look on URL you posted, thanks! > > RTP is perhaps the wrong reference, I should have referred the > different overlay tunnels as NVO3 "codecs", the payload inside the > RTP, the audio/video profile

Re: [nvo3] Consensus call on encap proposals

;> 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:

Re: [nvo3] Consensus call on encap proposals

-- > From: Alia Atlas <akat...@gmail.com <mailto:akat...@gmail.com>> > To: NVO3 <nvo3@ietf.org <mailto:nvo3@ietf.org>> > Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com > <mailto:matthew.bo...@nokia.com>> &g

Re: [nvo3] Consensus call on encap proposals

; > 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 th

Re: [nvo3] Consensus call on encap proposals

On 7/22/16 9:47 AM, Tom Herbert wrote: On Jul 22, 2016 11:44 AM, "Tom Herbert" > wrote: > > On Jul 22, 2016 3:38 AM, "Dino Farinacci" > wrote: > > > > > - VXLAN-GPE does not appear compatible

Re: [nvo3] Consensus call on encap proposals

On Fri, Jul 29, 2016 at 1:34 AM, Naoki Matsuhira 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

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

Re: [nvo3] Consensus call on encap proposals

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

Re: [nvo3] Consensus call on encap proposals

On 7/27/16 12:27 PM, Tom Herbert wrote: On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino wrote: On 7/27/16 10:53 AM, Tom Herbert wrote: On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci wrote: On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)

Re: [nvo3] Consensus call on encap proposals

On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino wrote: > On 7/27/16 10:53 AM, Tom Herbert wrote: >> >> On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci >> wrote: On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) wrote: >

Re: [nvo3] Consensus call on encap proposals

> As do Geneve and GUE. But this thread is not about touting the > features of these protocols, it is about the technical objections to > them. My major objections (from the list I posted) to VXLAN-GPE is > that it has no extensibility and offers no security of the VNI. These > are showstoppers in

Re: [nvo3] Consensus call on encap proposals

On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci wrote: >> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) wrote: >>> >>> On 7/26/16 12:08 PM, Dino Farinacci wrote: > Having VXLAN as an Independent Stream RFC gives a document to be used to >

Re: [nvo3] Consensus call on encap proposals

On 7/27/16 10:53 AM, Tom Herbert wrote: On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci wrote: On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) wrote: On 7/26/16 12:08 PM, Dino Farinacci wrote: Having VXLAN as an Independent Stream RFC gives a

Re: [nvo3] Consensus call on encap proposals

Resending with some edits (post coffee). As asked in the original email, please do provide technical objections to the solutions within the NVo3 WG. This will enable to form consensus in order to resolve the issues and come up with a solution(s) adopted by WG @IETF. As mentioned by Alia,

Re: [nvo3] Consensus call on encap proposals

> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) wrote: >> >> On 7/26/16 12:08 PM, Dino Farinacci wrote: Having VXLAN as an Independent Stream RFC gives a document to be used to innovate from. I believe that was the intent of VXLAN-GPE - to provide the

Re: [nvo3] Consensus call on encap proposals

> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) wrote: > > On 7/26/16 12:08 PM, Dino Farinacci wrote: >>> Having VXLAN as an Independent Stream RFC gives a document to be used to >>> innovate from. I believe that was the intent of VXLAN-GPE - to provide >>> the ability

Re: [nvo3] Consensus call on encap proposals

As asked in the original email, please do provide technical objections to the solutions within the NVo3 WG. This will enable to form consensus in order to resolve the issues and come up with a solution(s) adopted by WG @IETF. As mentioned by Alia, consensus and decision process will be based on

Re: [nvo3] Consensus call on encap proposals

On Tue, Jul 26, 2016 at 8:33 PM, Xuxiaohu wrote: > I fully agree with Dino's points. Before picking one of the three WG docs as > a candidate to publish, we'd better evaluate whether those already published, > implemented and deployed NVo3 technologies (see below) are good

Re: [nvo3] Consensus call on encap proposals

Jesse Gross <jgr...@vmware.com<mailto:jgr...@vmware.com>>, "Larry Kreeger (kreeger)" <kree...@cisco.com<mailto:kree...@cisco.com>> Subject: Re: [nvo3] Consensus call on encap proposals I know it's tempting to dive into technology details and micro-optimization, but c

Re: [nvo3] Consensus call on encap proposals

chsmit) > Cc: Tom Herbert; nvo3@ietf.org; Alia Atlas; Matthew Bocci; Paul Quinn; Jesse > Gross; Larry Kreeger > Subject: Re: [nvo3] Consensus call on encap proposals > > The IETF should not encourage more options. Standards are suppose to unify > interoperability not cause mor

Re: [nvo3] Consensus call on encap proposals

2016 4:45 PM >> To: Alia Atlas; Joe Touch >> Cc: Tom Herbert; Michael Smith (michsmit); nvo3@ietf.org; Matthew Bocci; >> Paul Quinn; Dino Farinacci; Jesse Gross; Larry Kreeger >> Subject: Re: [nvo3] Consensus call on encap proposals >> >> Hi Alia, &g

Re: [nvo3] Consensus call on encap proposals

] *On Behalf Of *Reith, Lothar *Sent:* Tuesday, July 26, 2016 4:45 PM *To:* Alia Atlas; Joe Touch *Cc:* Tom Herbert; Michael Smith (michsmit); nvo3@ietf.org; Matthew Bocci; Paul Quinn; Dino Farinacci; Jesse Gross; Larry Kreeger *Subject:* Re: [nvo3] Consensus call on encap proposals Hi Alia, I

Re: [nvo3] Consensus call on encap proposals

To: Alia Atlas; Joe Touch Cc: Tom Herbert; Michael Smith (michsmit); nvo3@ietf.org; Matthew Bocci; Paul Quinn; Dino Farinacci; Jesse Gross; Larry Kreeger Subject: Re: [nvo3] Consensus call on encap proposals Hi Alia, I fully support your approach. I am strongly in favor of moving forward

Re: [nvo3] Consensus call on encap proposals

atthew.bo...@nokia.com>; > Paul Quinn <pa...@cisco.com>; Dino Farinacci <farina...@gmail.com>; Jesse > Gross <jgr...@vmware.com>; Larry Kreeger <kree...@cisco.com> > *Betreff:* Re: [nvo3] Consensus call on encap proposals > > > > On Tue, Jul 26, 2016

Re: [nvo3] Consensus call on encap proposals

om>; Dino Farinacci <farina...@gmail.com>; Jesse Gross <jgr...@vmware.com>; Larry Kreeger <kree...@cisco.com> Betreff: Re: [nvo3] Consensus call on encap proposals On Tue, Jul 26, 2016 at 3:50 PM, Joe Touch <to...@isi.edu<mailto:to...@isi.edu>> wrote: On 7/26/2016 12:42 PM

Re: [nvo3] Consensus call on encap proposals

[mailto:nvo3-boun...@ietf.org] On Behalf Of Alia Atlas Sent: Tuesday, July 26, 2016 3:05 PM To: Joe Touch Cc: Tom Herbert; Michael Smith (michsmit); nvo3@ietf.org; Matthew Bocci; Paul Quinn; Dino Farinacci; Jesse Gross; Larry Kreeger Subject: Re: [nvo3] Consensus call on encap proposals On Tue, Jul

Re: [nvo3] Consensus call on encap proposals

On Tue, Jul 26, 2016 at 3:50 PM, Joe Touch wrote: > > > On 7/26/2016 12:42 PM, Alia Atlas wrote: > > ... > > The question is: > > (1) Should the WG move forward with one standards track encap? > > I've heard a lot of concern that we just can't do it, that it's too late, > etc. > >

Re: [nvo3] Consensus call on encap proposals

When the current architecture is broken, you have to use what works. Just one example is NAT-traversal. UDP is the only choice. And default-off is a feature. Dino P.S. Ending thread per Alia’s request to stay on topic of a decision. > On Jul 26, 2016, at 12:46 PM, Joe Touch

Re: [nvo3] Consensus call on encap proposals

On 7/26/2016 12:42 PM, Alia Atlas wrote: > ... > > The question is: > > (1) Should the WG move forward with one standards track encap? > > I've heard a lot of concern that we just can't do it, that it's too > late, etc. I don't think it's ever "too late", but I also don't see consensus forming

Re: [nvo3] Consensus call on encap proposals

On 7/26/2016 12:41 PM, Dino Farinacci wrote: > Sorry, not convinced. What you point me to is general services that run at a > session layer. We are talking about using (err, misusing?) UDP for a network > layer function. That BCP applies to *all* services assigned transport protocol port

Re: [nvo3] Consensus call on encap proposals

Some other points: On 7/26/2016 12:22 PM, Dino Farinacci wrote: > Now, let’s think about this. Why waste 4-bits or a byte for every single > packet when the UDP port number can be your version number. That UDP port > number has to be in every single packet anyways. > > Why keep the port number

Re: [nvo3] Consensus call on encap proposals

I know it's tempting to dive into technology details and micro-optimization, but can we please stay focused. This is already a rather long thread - and I am strongly hoping to hear from those who aren't championing their own technology. The question is: (1) Should the WG move forward with one

Re: [nvo3] Consensus call on encap proposals

Sorry, not convinced. What you point me to is general services that run at a session layer. We are talking about using (err, misusing?) UDP for a network layer function. Dino > On Jul 26, 2016, at 12:32 PM, Joe Touch wrote: > > Read BCP 165. > > The cost to your protocol is

Re: [nvo3] Consensus call on encap proposals

Read BCP 165. The cost to your protocol is as little as 1 bit and it protects a global resource. Joe > On Jul 26, 2016, at 12:22 PM, Dino Farinacci wrote: > > Now, let’s think about this. Why waste 4-bits or a byte for every single > packet when the UDP port number can

Re: [nvo3] Consensus call on encap proposals

Exactly Dino. Its puzzling why this is even being debated. —Tom > On Jul 26, 2016:3:08 PM, at 3:08 PM, Dino Farinacci > wrote: > >> Having VXLAN as an Independent Stream RFC gives a document to be used to >> innovate from. I believe that was the intent

Re: [nvo3] Consensus call on encap proposals

Now, let’s think about this. Why waste 4-bits or a byte for every single packet when the UDP port number can be your version number. That UDP port number has to be in every single packet anyways. Why keep the port number the same and change the version number when the same cost of product

Re: [nvo3] Consensus call on encap proposals

On 7/26/2016 11:59 AM, Michael Smith (michsmit) wrote: > Agreed. Given that considerable time has past since the initial decision > and as long as we are re-visiting it, why not adopt VXLAN ? It has seen > considerable deployment and implementation. Its format is compatible with > LISP which

Re: [nvo3] Consensus call on encap proposals

> On 7/26/16 12:08 PM, Dino Farinacci wrote: >>> Having VXLAN as an Independent Stream RFC gives a document to be used to >>> innovate from. I believe that was the intent of VXLAN-GPE - to provide >>> the ability >>> for needed extensions. >> The only new feature the VXLAN-GPE brings to the

Re: [nvo3] Consensus call on encap proposals

On 7/26/16 12:08 PM, Dino Farinacci wrote: Having VXLAN as an Independent Stream RFC gives a document to be used to innovate from. I believe that was the intent of VXLAN-GPE - to provide the ability for needed extensions. The only new feature the VXLAN-GPE brings to the table is a way to

Re: [nvo3] Consensus call on encap proposals

> Having VXLAN as an Independent Stream RFC gives a document to be used to > innovate from. I believe that was the intent of VXLAN-GPE - to provide the > ability > for needed extensions. The only new feature the VXLAN-GPE brings to the table is a way to identify that NSH is being

Re: [nvo3] Consensus call on encap proposals

Having VXLAN as an Independent Stream RFC gives a document to be used to innovate from. I believe that was the intent of VXLAN-GPE - to provide the ability for needed extensions. >From an IETF perspective, it is critical to have an encapsulation that can provide reasonable OAM and at least the

Re: [nvo3] Consensus call on encap proposals

Agreed. Given that considerable time has past since the initial decision and as long as we are re-visiting it, why not adopt VXLAN ? It has seen considerable deployment and implementation. Its format is compatible with LISP which serves to provide a common frame format for L2 and L3 overlays. One

Re: [nvo3] Consensus call on encap proposals

Users already have to deal with multiple solutions for network overlays in the form of VXLAN and NVGRE. Neither of which is listed as an option here. Picking 1 more solution or 3 more solutions won¹t improve that. On 7/25/16, 6:57 PM, "nvo3 on behalf of Tom Herbert"

Re: [nvo3] Consensus call on encap proposals

+1 On 26 July 2016 04:57:34 EEST, Tom Herbert wrote: >> I believe that others are in a similar position but opposite with >regards to >> technical choices. The net result is that there are almost certain to >be >> multiple formats in the wild regardless of what is decided

Re: [nvo3] Consensus call on encap proposals

> I believe that others are in a similar position but opposite with regards to > technical choices. The net result is that there are almost certain to be > multiple formats in the wild regardless of what is decided here. Yes, that > means letting the market decide rather than the IETF. I honestly

Re: [nvo3] Consensus call on encap proposals

Hi, Alia, One one minor point: On 7/25/2016 11:40 AM, Alia Atlas wrote: > > As a consequence, a small set of reasonably distinct encapsulation > designs can and should proceed as either Informational or Experimental > as per the NVO3 charter. > > > I think that they would go as

Re: [nvo3] Consensus call on encap proposals

> > > *From:* nvo3 [mailto:nvo3-boun...@ietf.org] *On Behalf Of *Jesse Gross > *Sent:* Monday, July 25, 2016 10:52 AM > *To:* Alia Atlas > *Cc:* Matthew Bocci; Larry Kreeger (kreeger); nvo3@ietf.org; Paul Quinn > (paulq) > *Subject:* Re: [nvo3] Consensus call on e

Re: [nvo3] Consensus call on encap proposals

On 7/25/16 8:52 AM, Jesse Gross wrote: I believe that others are in a similar position but opposite with regards to technical choices. The net result is that there are almost certain to be multiple formats in the wild regardless of what is decided here. Yes, that means letting the market

Re: [nvo3] Consensus call on encap proposals

Hi, all, I sincerely hope it is never appropriate to act solely on events at an IETF meeting, but that this is taken only as a first-step to mailing list coordination. Many people participate online - whether because they didn't attend the meeting, because they feel more comfortable responding

Re: [nvo3] Consensus call on encap proposals

On Jul 25, 2016, at 7:38 AM, Alia Atlas > wrote: Hi Paul, On Mon, Jul 25, 2016 at 10:23 AM, Paul Quinn (paulq) > wrote: Alia, On Jul 21, 2016, at 7:12 PM, Alia Atlas

Re: [nvo3] Consensus call on encap proposals

Alia, On Jul 21, 2016, at 7:12 PM, Alia Atlas > wrote: Hi Larry, Very briefly in-line. On Jul 21, 2016 10:04 PM, "Larry Kreeger (kreeger)" > wrote: > > Hi Matthew, > > See my responses inline below. > >

Re: [nvo3] Consensus call on encap proposals

supports both >> VXLAN and VXLAN-GPE. Our customers can indeed support both on the same >> hardware. >> >> >> >> David >> >> >> >> *From:* nvo3 [mailto:nvo3-boun...@ietf.org] *On Behalf Of *Jon Hudson >> *Sent:* Friday, July 22,

Re: [nvo3] Consensus call on encap proposals

..@ietf.org>] On Behalf Of Jon Hudson Sent: Friday, July 22, 2016 11:58 AM To: Dino Farinacci Cc: Matthew Bocci; Tom Herbert; nvo3@ietf.org<mailto:nvo3@ietf.org> Subject: Re: [nvo3] Consensus call on encap proposals On Fri, Jul 22, 2016 at 1:38 AM, Dino Farinacci <farina...@gma

Re: [nvo3] Consensus call on encap proposals

support both on the same > hardware. > > > > David > > > > *From:* nvo3 [mailto:nvo3-boun...@ietf.org] *On Behalf Of *Jon Hudson > *Sent:* Friday, July 22, 2016 11:58 AM > *To:* Dino Farinacci > *Cc:* Matthew Bocci; Tom Herbert; nvo3@ietf.org > *Subject:* Re: [nvo

Re: [nvo3] Consensus call on encap proposals

Farinacci <farina...@gmail.com> Cc: Matthew Bocci <matthew.bo...@nokia.com>; Tom Herbert <t...@herbertland.com>; nvo3@ietf.org Subject: Re: [nvo3] Consensus call on encap proposals On Fri, Jul 22, 2016 at 1:38 AM, Dino Farinacci <farina...@gmail.com<mailto:farina...@gmai

Re: [nvo3] Consensus call on encap proposals

On Jul 22, 2016 11:44 AM, "Tom Herbert" wrote: > > On Jul 22, 2016 3:38 AM, "Dino Farinacci" wrote: > > > > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host receives a VXLAN packet for some protocol other than Ethern the payload

Re: [nvo3] Consensus call on encap proposals

On Jul 22, 2016 3:38 AM, "Dino Farinacci" wrote: > > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host receives a VXLAN packet for some protocol other than Ethern the payload will be misinterpreted. A separate port number was required. I assume that a

Re: [nvo3] Consensus call on encap proposals

customers can indeed support both on the same hardware. David From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Jon Hudson Sent: Friday, July 22, 2016 11:58 AM To: Dino Farinacci Cc: Matthew Bocci; Tom Herbert; nvo3@ietf.org Subject: Re: [nvo3] Consensus call on encap proposals On Fri, Jul

Re: [nvo3] Consensus call on encap proposals

On Jul 22, 2016, at 10:38 AM, Dino Farinacci wrote: > I am told you can do this with BGP as well by negotiating what encapsulations > are supported. Of course, this also applies to any other encapsulation protocol, both BGP and other control planes have done this. I don't

Re: [nvo3] Consensus call on encap proposals

> On Jul 21, 2016, at 4:56 PM, Bocci, Matthew (Nokia - GB) > wrote: > 2) Does anyone have a significant technical objection to selecting VXLAN-GPE > as the single NVO3 Standards track document? Please be as concrete and > detailed as possible as to your technical

Re: [nvo3] Consensus call on encap proposals

> On Fri, Jul 22, 2016 at 1:38 AM, Dino Farinacci wrote: > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host > > receives a VXLAN packet for some protocol other than Ethern the payload > > will be misinterpreted. A separate port number was required. I

Re: [nvo3] Consensus call on encap proposals

On Fri, Jul 22, 2016 at 1:38 AM, Dino Farinacci wrote: > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host > receives a VXLAN packet for some protocol other than Ethern the payload > will be misinterpreted. A separate port number was required. I assume

Re: [nvo3] Consensus call on encap proposals

> - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host > receives a VXLAN packet for some protocol other than Ethern the payload will > be misinterpreted. A separate port number was required. I assume that a user > using VXLAN in HW must upgrade HW to use VXLAN-GPE Tom, one

Re: [nvo3] Consensus call on encap proposals

On Jul 21, 2016 4:56 PM, "Bocci, Matthew (Nokia - GB)" < matthew.bo...@nokia.com> 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

Re: [nvo3] Consensus call on encap proposals

On Jul 22, 2016 12:13 AM, "Dino Farinacci" wrote: > > > These are data plane functions for ingress/egress processing, which > > already does things like IPsec tunnel mode, IP in IP, IP in UDP in IP, etc. > > All with fix length headers. These packet formats allow the hardware

Re: [nvo3] Consensus call on encap proposals

Joe, let’s agree to disagree. Thanks for the discussion. Dino > On Jul 21, 2016, at 4:04 PM, Joe Touch wrote: > > > > On 7/21/2016 3:57 PM, Dino Farinacci wrote: >> >>> Port numbers are assigned for entire services, not for each component >>> nor for each version of a

Re: [nvo3] Consensus call on encap proposals

Hi Larry, Very briefly in-line. On Jul 21, 2016 10:04 PM, "Larry Kreeger (kreeger)" wrote: > > Hi Matthew, > > See my responses inline below. > > Thanks, Larry > > > > On 7/21/16, 7:56 AM, "nvo3 on behalf of Bocci, Matthew (Nokia - GB)" >

Re: [nvo3] Consensus call on encap proposals

On 7/21/2016 3:57 PM, Dino Farinacci wrote: > >> Port numbers are assigned for entire services, not for each component >> nor for each version of a protocol anymore (see the two docs of BCP > GUE is a different service than Geneve. They both have different ports, do > they not? Yes, those are

Re: [nvo3] Consensus call on encap proposals

> On 7/21/2016 3:37 PM, Dino Farinacci wrote: >>> Thanks - I was trying to understand the basis of your objection. >> No prob. >> >>> You appear to be against variable packet formats in an form (which is >>> your choice, but I don't understand how we can develop protocols that >>> aren't

Re: [nvo3] Consensus call on encap proposals

On 7/21/2016 3:37 PM, Dino Farinacci wrote: >> Thanks - I was trying to understand the basis of your objection. > No prob. > >> You appear to be against variable packet formats in an form (which is >> your choice, but I don't understand how we can develop protocols that >> aren't instantly

Re: [nvo3] Consensus call on encap proposals

> Thanks - I was trying to understand the basis of your objection. No prob. > You appear to be against variable packet formats in an form (which is > your choice, but I don't understand how we can develop protocols that > aren't instantly ossified that way). Back during the IPng directorate

Re: [nvo3] Consensus call on encap proposals

Thanks - I was trying to understand the basis of your objection. You appear to be against variable packet formats in an form (which is your choice, but I don't understand how we can develop protocols that aren't instantly ossified that way). You also seem to think security is optional. It

Re: [nvo3] Consensus call on encap proposals

> These are data plane functions for ingress/egress processing, which > already does things like IPsec tunnel mode, IP in IP, IP in UDP in IP, etc. All with fix length headers. These packet formats allow the hardware to do a few input checks in fixed places. Crypto is way different and a very

Re: [nvo3] Consensus call on encap proposals

On 7/21/2016 1:22 PM, Dino Farinacci wrote: >> Dino, >> >> I'm curious - what is your basis for "cost”? > (1) Time to market due to complexity in chip design. > (2) More are used for logic versus needed SRAM space for table entries. > (3) Additional latency in processing packets. > >> The

Re: [nvo3] Consensus call on encap proposals

> Dino, > > I'm curious - what is your basis for "cost”? (1) Time to market due to complexity in chip design. (2) More are used for logic versus needed SRAM space for table entries. (3) Additional latency in processing packets. > The overheads in these protocols is as low as any other currently

Re: [nvo3] Consensus call on encap proposals

Hi Matthew, See my responses inline below. Thanks, Larry On 7/21/16, 7:56 AM, "nvo3 on behalf of Bocci, Matthew (Nokia - GB)" wrote: >WG > >There was a discussion in the NVO3 WG meeting in Berlin following strong >advice from our

Re: [nvo3] Consensus call on encap proposals

Dino, I'm curious - what is your basis for "cost"? The overheads in these protocols is as low as any other currently in widespread use. Joe On 7/21/2016 11:24 AM, Dino Farinacci wrote: >> 1) Does anyone have a significant technical objection to selecting Geneve as >> the single NVO3 Standards

Re: [nvo3] Consensus call on encap proposals

> 1) Does anyone have a significant technical objection to selecting Geneve as > the single NVO3 Standards track document? Please be as concrete and detailed > as possible as to your technical objection. I object to Geneve because it will not be a cost-effective solution in all types of