Hi all, For now the drafts proposed for adoption in NVO3 have currently formulated the isolation requirements in terms such as "a tenant's traffic is not visible to any other tenant", and moves the topic of inter-tenant communication outside the NVO3 scope, merely suggesting that if some tenant "traffic" can be made visible to another tenant this shall happen though some kind of gateway.
See for instance, the following pieces of text in draft-narten-nvo3-overlay-problem-statement: > Abstract > > [...] A key multi-tenancy > requirement is traffic isolation, so that a tenant's traffic is not > visible to any other tenant. [...] > [...] > 1. Introduction > > [...] > For example, one tenant's traffic must never be > exposed to another tenant, except through carefully controlled > interfaces, such as a security gateway. > [...] > the only end stations connected to the virtual network are those > belonging to > the tenant. > [...] > The key requirement is > that each individual virtual network instance be isolated from other > virtual network instances. (don't interpret this as a criticism of draft-narten-nvo3-overlay-problem-statement per-se, other drafts have similar text, for instance draft-lasserre-nvo3-framework) For L2 virtual network instances, which emulate a LAN, connectivity to the outside is supposed to happen through an IP routing stack (a "router" or a "gateway", depending how you like to call it); this IP routing stack being a place where routes and policy can be established to provide connectivity with other networks (virtual or non virtual). Putting this part of the issue explicitly *in* the scope of NVO3 would put us is a better situation to handle inter-tenant traffic in a distributed manner rather than by requiring a detour through some specific NVE acting as a gateway between tenants. For L3 virtual network instances, the current formulation is I think even more problematic. I have got a very hard time figuring out what a sentence like "end stations connected to the virtual network are those belonging to the tenant" means in the context of L3 inter-tenant traffic: as soon as IP connectivity exists between two IP hosts, they can be said being "connected", and thus we lose any usable distinction between VM that is part of a tenant from another VM part of another tenant but having connectivity to the first one. To refine our problem statement to address the above, I think we have to introduce a finer-grained notion than the notion "virtual network instance". One connectivity model is clearly defined and well in line with the notion of "virtual network instance" is the case of full-mesh connectivity between a set of VMs ; at L2 this has the same properties as a LAN, and at L3 of a flat network before any filtering policy is applied. There are other connectivity models that are useful to consider. For instance hub'n'spoke: one set of VM (set H) having connectivity with another set of VMs (set S), without VMs in H having connectivity to another VMs in H (one example could be: S is a set of storage service nodes, and H is the set of VMs accessing the service); such a hub'n'spoke model is very relevant for L3, but could be for L2 as well (e.g. such requirements are addressed by the l2vpn WG under the E-tree name). Many combination can actually prove useful. More generally, at least for layer 3, we should be able with NVE3 mechanisms to define a VM as being part of multiple sets of VMs, with means to define, for each set of VMs, if connectivity is allowed inside the set (yes for a full-mesh, no for a set of hubs in a hub'n'spoke), and with which other sets connectivity is to be allowed. Even for L2, since at some point, at least some of the end systems in a L2 full-mesh tenant will have to exchange traffic with the outside world, it will be very beneficial to be able to say that a set of VMs in a full-mesh L2 virtual network has IP connectivity to other sets of VMs. I think this should lead us to naturally conclude that it is useful to consider the scenario where and NVE, for one said VNI, should be able to forward traffic based whether on the destination MAC address or the destination IP address. Beyond the details above, I want to insist that we should properly document the need to address inter-tenant connectivity as part of the problem statement and framework drafts. -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
