I agree with adopting draft-narten-nvo3-overlay-problem-statement-04 as a problem statement.
I have three comments: 1) I am surprised that there is a view that bridges/virtual-switches located in hypervisors will be among those most constrained. I think that things located in the hypervisor are not constrained in terms of code space or code update latency. (By "code update latency", I mean, how quickly a patch can be deployed. No silicon is involved, no firmware needs to be updated, a simple patch and reboot of a server is enough. Perhaps there is another term for this) It could be that hypervisors, having hundreds of instances of virtual switches maybe constrained as to amount of memory used by each instance, but comparing that to ToR switches, I think that they have huge amounts of memory available. 2) I did not get a clear idea that we are looking at only solutions that provide layer-2 services. I think that this is the case, but it felt to me that some layer-3 solutions (ones that did not require renumbering) might be still in the running. For instance, creative use of proxy-arp (or layer-3 meshes like OLSRV) might be admissible. These have limitations for multicast and broadcast traffic which are both features and hindrances. 3) I would like some guidance as to why the problem that NVO3 is dealing with was out of scope for, for instance, TRILL. Not just a statement that TRILL has a GAP, but a clear indication why that GAP isn't something that TRILL should solve.... also why this problem is an IETF problem, and not an IEEE problem. -- Michael Richardson -at the cottage-
pgpYyX0XXBSko.pgp
Description: PGP signature
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
