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 close to what we have been showing to customers as a product
prototype and will be shipping in the near future. Namely - I like the
presence of the physical(s) in the top right corner. Physicals are an
integral part of a datacenter and need to talk to the overlay too.
It is quite sad that after getting this right, the draft cripples it by
limiting the scope and failing to address what is actually shown on that
diagram.
In order for physicals to talk to the overlay they need to be able to
connect to the overlay. In real life this means well known and well
supported encapsulations - EoGRE, EoL2TPv3 and more recently VXLAN. The
former two are supported on most "hosts" as well as nearly all network
equipment. The latter is getting there too. A new and wonderful
encapsulation which on top of all is not directly supported and mandates
me to run a virtual switch everywhere is not a "well supported
encapsulation". It does not fit the bill and does not match the diagram.
There are two ways to approach this from here onwards. One is to
continue the critique and discussion. IMHO this is pointless and
violates the spirit of IETF: "We believe in rough consensus and working
code".
The consensus is there - most of the networking world uses either EoGRE
or EoL2TPv3 (VXLAN has its established use cases too). These are
established standards with RFCs. We will now _ADD_ _THE_ _CODE_ so we
can get out of this "I'd like to invent a new encapsulation today"
madness once and for all.
* We just contributed a GPL2 EoL2TPv3 direct support for qemu-kvm to
the qemu project.
* We also made a binding promise to offer equivalent code to UML (we
have the code there, just the patch-sets are too big to submit at once).
* Containers can talk EoL2TPv3 directly already.
All of these can use this to talk directly VM to VM, Physical to VM and
Switch to VM (as on the diagram).
It is fully supported for switching - you simply configure a EoL2TPv3
interface on your local host and bring it into OVS, Bridge or other
local switching system of your choice. You can also switch remotely -
the NVE is no longer mandatory co-hosted on the same machine. So if you
want to do all of your datacenter switching on a "big router/switch" you
can now do so. All of them can talk the encaps, most have support for
running thousands (some up to tens and hundreds of thousands) of NVEs too.
You also can talk to host - just configure a tunnel "to yourself". Most
importantly you can talk VM to VM and VM to physical router as needed
for service chaining.
This brings me back to the caption under the diagram. That caption is
complete nonsense. You can implement means of communicating between all
the elements on it without a mandatory switch. Why on earth do you need
to cripple the spec and specify it after that?
I am aware that EoLT2Pv3 is not a candidate for NVO3 at present. We will
address that by contribute equivalent GRE code at a later date (next
couple months).
In fact, anyone can take the driver we contributed and make it support
GRE, Geneve or carrier pigeons. This is because this contribution has
produced an interesting side effect - anyone who would like to implement
in software a new encaps that can be presented as a socket interface on
a host running Type 2 environment can now do so in an afternoon or less.
It is no longer "state of the art" activity. The barrier to entry and
the technical merit of "new encaps" if it is only an encaps (no control
plane component) has just been lowered to somewhere around zero. It is
now "boring".
This is inclusive of Geneve itself. As it has no other merit besides
being new encaps I do not see why it should be left to live under these
circumstances. I'd rather have people include the remaining key encaps
out there - L2TPv3 and concentrate on getting the control plane portion
working.
Some final clarifications:
1. Drafts - L2TPv3 is an RFC and has been around for many years. There
is no need for extra drafts.
2. IPR - the same mechanics for overlay termination have been used in
storage for many years providing a plethora of prior art. Similarly,
non-standard versions of the same approach (VDE, socket,etc) have been
around since the dawn of qemu and UML. There is nothing to patent here.
A
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
