Hi all,
I just finished reading this draft.
I am going to ignore the caption under the diagram at this point - it
does not match to the diagram and neither does the rest of the draft (we
will come back to it later).
So, first and foremost, the diagram. I actually really like it. It is
very
If you have a presentation slot in London next week, please can you send your
slides by 8pm GMT on Sunday.
We have a very full agenda, so we will remove any presentation slots for which
we have not received slides or been notified by the presenter that they do not
need slides.
Thanks
Matthew
The diagram in the Geneve draft depicts tunnels terminating on both virtual
switches in a Hypervisor, as well as physical switches connecting to
non-virtual physical hosts.
As such, the later brings the physical hosts into the overlay without any
modification to the software stack on the
On 28/02/14 14:14, Brad Hedlund wrote:
The diagram in the Geneve draft depicts tunnels terminating on both virtual
switches in a Hypervisor, as well as physical switches connecting to
non-virtual physical hosts.
As such, the later brings the physical hosts into the overlay without any
The Geneve draft proposes a 24-bit VNI, in addition to 32-bits of Variable
Length Options.
Those later 32 bits can be used entirely by the system designer for carrying
implementation specific metadata, such as for example carrying service chaining
relevant information from one middle-box to the
On 28/02/14 15:08, Brad Hedlund wrote:
The Geneve draft proposes a 24-bit VNI, in addition to 32-bits of Variable
Length Options.
Those later 32 bits can be used entirely by the system designer for carrying
implementation specific metadata, such as for example carrying service
chaining
On 28/02/14 15:30, Pankaj Garg wrote:
Yes, the key differentiator in Geneve is to allow multiple variable length
options in the unit of 32-bits, _without_ breaking hardware offloads that are
critical for software endpoint performance. These options can be standard
options or vendor
That work (chaining and metadata) is already being addressed in the SFC
workgroup by charter. At the very least, the draft should move if that's
it's primary thrust. In that work, there is no coupling between the
header for forwarding in an overlay and the header for chaining and
passing
Geneve options are not specific to service chaining, though a service chain
blob can be one of the option in Geneve header. So it does belongs to network
virtualization encapsulation format and not to SFC charter.
-Original Message-
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf
On 28/02/14 16:26, Pankaj Garg wrote:
Geneve options are not specific to service chaining, though a service chain
blob can be one of the option in Geneve header. So it does belongs to network
virtualization encapsulation format and not to SFC charter.
Disagree.
From an encapsulation
We can discuss merits of Geneve vs VXLAN vs NVGRE vs STT vs L2TPV3 vs Name
your favorite protocol when it comes to standardization for network
virtualization. My point was that Geneve is designed for network virtualization
and not only for service chaining. We have many use cases of ability to
On 28/02/14 16:57, Pankaj Garg wrote:
We can discuss merits of Geneve vs VXLAN vs NVGRE vs STT vs L2TPV3 vs Name
your favorite protocol when it comes to standardization for network
virtualization.
I already said what I had to say here. There is no discussion to be had.
My point was that
The definition of meta-data for a feature should come from their respective WG,
e.g. service-chaining blob design should come from SFC. How, the meta-data data
is carried in an encapsulation comes from the design of the encapsulation
format. The point of Geneve is that it would allow the
On 28/02/14 18:28, Pankaj Garg wrote:
The definition of meta-data for a feature should come from their respective
WG, e.g. service-chaining blob design should come from SFC. How, the
meta-data data is carried in an encapsulation comes from the design of the
encapsulation format. The point
I see that a healthy discussion has broken out around draft-gross-geneve-00
which I see has a slot in the agenda for the NVO3 WG meeting on Monday. Here
are my thoughts.
I will be comparing Geneve to an encapsulation that is near and dear to my
heart, VXLAN. When I do this, I see an
So Larry, earlier in the month I asked the chairs if nvo3 was ready to talk and
explore solutions. The answer was no.
Then why is GENEVE on the agenda chairs?
Dino
On Feb 28, 2014, at 1:57 PM, Larry Kreeger (kreeger) kree...@cisco.com
wrote:
I see that a healthy discussion has broken
Hi all,
Read the draft but have few questions on the same line others have asked.
- Is this draft intended for standardizing within NVo3 WG? The status
indicates it as informational. Also it is good to have it as
draft-nvo3, if it is meant for NVo3 WG.
- I fail to find good reasoning, in the
On Fri, Feb 28, 2014 at 3:24 PM, Sam Aldrin aldrin.i...@gmail.com wrote:
Hi all,
Read the draft but have few questions on the same line others have asked.
- Is this draft intended for standardizing within NVo3 WG? The status
indicates it as informational. Also it is good to have it as
18 matches
Mail list logo
