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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
>>
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
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),
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:
>
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
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
gt;>
>>
>>
>>>
>>> -- Forwarded message --
>>> From: Alia Atlas <akat...@gmail.com>
>>> To: NVO3 <nvo3@ietf.org>
>>> Cc: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.c
Date: Fri, 29 Jul 2016 11:13:00
-0400
Subject: Re: [nvo3] Consensus call
on encap proposals
I'd like to have
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
;> 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:
--
> 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
;
> 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
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
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
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
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
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)
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:
>
> 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
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
>
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
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,
> 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
> 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
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
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
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
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
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
] *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
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
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
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
[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
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.
>
>
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
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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
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
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"
+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
> 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
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
>
>
> *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
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
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
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
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.
>
>
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,
..@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
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
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
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
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
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
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
> 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
> 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
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
> - 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
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
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
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
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)"
>
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
> 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
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
> 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
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
> 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
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
> 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
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
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
> 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
99 matches
Mail list logo