[occi-wg] Networks: attributes and verbs

[Lars Larsson]

Hello all,

I would definitely like to keep an "infrastructure perspective" 
with regard to networking. I think that what the OCCI should 
expose is nothing more than I would get if I rented physical 
hardware: I, as the customer, get to define virtual networks and 
which machines I want to connect to these networks using which 
interfaces and which of these should have static IP addresses -- 
nothing else. This means, in particular, that I don't think that 
such additional services as (the configuration of) firewalls, 
DHCP servers, and the like should be included in the OCCI. If 
the customer requires these services, they should be implemented 
by VMs that are deployed on the customer's virtual network.

In my view, letting the customer deploy appliances both 
simplifies the infrastructure from an implementation point of 
view *and* at the same time gives the customer greater 
flexibility. We previously discussed that a DHCP server can be 
configured in minute detail, and while not all customers will 
take full advantage of such configuration possibilities, 
allowing them to make such configurations makes things much 
easier for all parties involved.

In such a scenario, a cloud provider could of course still 
define "Basic DHCP service" or "Basic Firewall" VMs with easy to 
use (web) interfaces so that customers that do not know iptables 
by heart can still be protected.

Best regards,

-- Lars

On Wed, 13 May 2009, Richard Davies wrote:

> All,
>
> For me, the largest gap in the nouns, verbs and attributes is with regards
> to networks. Here are some thoughts on capabilities which I believe we need
> and options to implement these - feedback please!
>
> Basics
> ------
> Networks will be a top level noun, along with servers and storage. Users
> will link a server to a network to specify that the server is attached to
> that network. There will be one special network presenting the public
> internet, and users can create additional private networks for themselves.
>
>
> The open questions are:
>
>
> Public static IPs
> -----------------
> On all public clouds, customers can purchase static IPs (e.g. Amazon Elastic
> IP) for uses where a constant server location is helpful (e.g. typical web
> hosting).
>
> We'll need a means for customers to create, list and destroy the public
> static IPs which they own.
>
> Two options:
> a) Public static IPs are first-class nouns
> b) They are listed inside the public internet network
>
> I'd favour a), which is the case with most public clouds today.
>
>
> Active networks
> ---------------
> At its most basic, a network should behave like a plain ethernet switch - it
> provides no services at all, and simply connects all the servers which
> attach to it. Servers are free to chose their own IP addresses, etc.
>
> There are a number of active services which are possible on a network:
> - Central DHCP server
> - Bridge to a physical VLAN (e.g. containing physical dedicated servers in
>  colocation with the cloud provider)
> - Load balancer between several web servers on a private network across to a
>  single IP on the public internet.
> - etc.
>
> Two options:
>
> a) The network object itself can optionally provide these. They are
>   configured using attributes and verbs on the network.
> b) There are separate 'appliance' objects which provide these services, and
>   are linked onto the network just as a server would be (e.g. a 'DHCP
>   server' appliance and or 'load balancer' appliance).
>
> a) feels lighter-weight, but I suspect b) is more powerful. As such the
> choice depends on how far OCCI wants to go down this route.
>
>
> Linking to a network
> --------------------
> Finally, there are a few attributes which can specified on the link when a
> server is linked to a network:
> - The physical interface on the server (nic:0, nic:1, etc.)
> - Port firewalling rules (e.g. connect server to the internet network, but only
>  allow port 80 inbound)
> - IP firewalling rules (e.g. connect server to the private network, and
>  allow it to communicate on 192.168.0.0-23 but no others)
> - Local DHCP (e.g. the server operating system is internally configured
>  to DHCP. I am connecting it to the public internet, and want it to appear
>  with my assigned public static IP. Please send a DHCP response with that
>  specific IP address).
>
> I think that all of these are best implemented as attributes on the link.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>