Hi folks, tl;dr: to have effective discussions at the Folsom summit, we need to agree on terminology more concrete than just talking about "L3", which means something different to different people. Some proposed definitions are below.
----------------------------------------------------------------------------------------------------------- Those of you that were around for the creation of Quantum at the Diablo summit will remember that one of the biggest challenges was that people frequently used terms (e.g., "network-as-a-service") for which we all had different definitions. I key step to making forward progress was to ban people from using terms like "network-as-a-service" and be more concrete. I think we're on the verge of a very similar situation with respect to the term "L3". Scoping and defining exactly what we're talking about for each session will be really important to making progress and avoid talking in circles. Therefore, I propose that we ban using the standalone term "L3" and instead use more concrete terms :) Let's first try to hash out a set of definitions that are reasonably well defined and well scoped (i.e., we use terms X and Y such that it is possible for us to say "that sounds like you're talking about topic Y, but this is the discussion on X. Lets hold off talking about that until we have the session on Y".). Once we have such a list, we can talk about how they map to sessions (it may be that two topics are so closely coupled that they cannot be discussed separately). This will also help us define dependencies. My main rational for splitting things into different items is if I could see a reasonable deployment that uses one capability but not another. - IP Address Management (IPAM): * How virtual servers as allocated IP addresses based on their network connectivity (http://en.wikipedia.org/wiki/IP_address_management) * Often includes other network identifiers that are also configured on a virtual server, including MAC address, subnet mask gateways, routes, DNS servers, etc. * This type of functionality is currently provided by Melange, which will be integrated into Quantum during Folsom. * IPAM is needed even if VMs are only connected to L2 Quantum networks (i.e., it does not required "L3 forwarding" or other logical features described below). * Note: this does NOT specify how these identifiers are "injected" into the server itself (could be via disk injections, DHCP, cloud-init+metadata, statically configured by admin) - DHCP Injection * A feature that allows VMs to issue DHCP requests on a Quantum network and receive a DHCP response that includes IPAM data specific to that VIF * In OpenStack, DHCP is used primarily for "injection", since IPAM is the ultimate source of truth for mapping MAC -> IP address and other network config (in some cases IPAM + DHCP are combined into a single product). * This is separate from IPAM since other injection mechanisms can be used. - L3 Forwarding * Quantum "networks" provide an L2 service model. There are use cases that require connecting servers that are not on the same L2 network + subnets, and are therefore connected only by an element performing L3 forwarding. * Note: this L3 forwarding element is a logical abstraction. We make no statement how how it is implemented (e.g., by a VM appliance, a physical router, or something else). * These L3 forwarding elements would likely expose some kind of a "routing table" to describe the rules used to forward between different L2-subnets. * A common use case is that an L2-network/subnet is a trust domain (private tenant networks, tier of a web application), yet communication is required between trust domains. * We separate out firewall and NAT into a separate discussion, below. * L3 forwarding has a dependency on understanding the IPAM data for a particular subnet that it is connected to (e.g., network address/mask, gateway address) - NAT * A common reason for deploying L3 Forwarding is to separate L2-networks/subnets that use private or overlapping IP space. NAT rewrites packets to map between different address spaces to allow communication. * includes source-NAT (SNAT) and destination-NAT (DNAT) rewriting. - Floating IPs * An existing API exposed in OpenStack (called "elastic IPs" in Amazon terminology) that allows tenants to setup "public" IPs that map to "private" IPs. * Can be implemented using DNAT rules, but exposes a higher level abstraction. * Has an IPAM component, as "public" IPs are allocated from one or more pools created by the provider. - Firewalling * Packet filtering performed by analyzing L3/L4 data in the packet and making a decision to allow or deny the traffic * Common forms include "security groups" and ACLs. * Firewalling may be applied on a per port basis (security groups, or "distributed firewall") or at a choke point such as a "L3 forwarding element" (see above). * Firewalling may or may not be "stateful", which refers to the ability to allow certain packets based on having already allowed other packets deemed to be part of the same "connection". * More advanced firewalling may include the ability to perform other operations, like mangle the packet, log the packet, etc. * Firewalling may be controlled by tenants, cloud operators, or some combination. Note: I'm not proposing the above terms as API abstractions, just as concrete terms we can use in discussion. I've put this list on the etherpad to help people add comments and thoughts without this turning into the email thread from hell (it can instead be the etherpad from hell...): http://etherpad.openstack.org/quantum-folsom Thanks, Dan -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
