Hi Robert,
Robert Raszuk:
The desire to have NVE in the hypervisor is dictated from the need to
build high speed IP based DC core including all tiers where devices
there do not need to keep any excessive state other then the basic
routing information how to carry already encapsulated packets to a next hop.
This is one of the motivations, but not necessarily the only one.
You slides have demonstrated the need to put CLOUD OS information to the
DC network (dotted lines) which completely prevents one to create low
cost high capacity IP core as it is quite unlikely that many vendors
would be able to deliver sufficient intelligence to integrate with CLOUD
OS (leave alone the aspect of cost).
I don't necessarily agree with you here. I'd actually be careful about
monolithic statements about cost, in general.
In this particular case the kind of interactions between the CloudOS and
the DC network may very much depend on your needs and on the
application, and may reduce down to mostly no interaction in some cases
(one reason for the line to be dotted, the other being that even if
their are some interactions, they are not in the critical path of VM
instantiation and VM mobility related actions).
I think there is definitely a space where just the right amount of
interaction happens between the CloudOS and DC network devices, with a
balanced additional effort on the network device vendor side.
Thinks like tenant virtualization local VLAN assignments are already
provided today by DC orchestration system when the VM is created. I do
not think that asking NVE TOR for this information as well as other
network information of VMs is a good direction at all.
Let's clarify two things:
- first of all, the draft allows VLAN allocation by the server *and*
allocation by the ToR (although one slide of our presentation only
highlighted one)
- second, about what you suggest above: "local VLAN assignment [...]
provided today by DC orchestration", having VLANs assigned by the DC
orchestration or cloud OS is something that does exists, *but* AFAICT
this is not about a *local* ID used only between the server and ToR (in
fact, it is precisely because it is local that you don't need to
coordinate the allocation at the DC orchestration level)
Thanks,
-Thomas
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
