Subject: [nvo3] Inter-tenant connectivity

From: <[email-masked]>
Date: Thu, 5 Jul 2012 13:23:01 +0000

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.

---

From: <[email-masked]>
Date: Thu, 5 Jul 2012 13:38:18 +0000

Hi all,

Ok, I've got a hard time catching up with email traffic and failed to 
identify that my email was somehow redundant with some emails in the 
inter-CUG thread.  Sorry about this.

Hopefully, a different formulation may still contribute to raising 
awareness on the fact that having a problem statement not taking into 
account such needs for efficient inter-tenant (or inter virtual network, 
inter-CUG) traffic, would put a excessive constraint on important scenarios.

One thing that we should have in mind is that an NVO3 overlay is also 
supposed to make easier the provisioning of virtual nework tenant.  So, 
the issue of inter-tenant connectivity is not only a matter of traffic 
optimality, but also a matter of keeping the efficiency and flexibility, 
including to establish L3 connectivity between tenants.

-Thomas