[occi-wg] Networks: attributes and verbs

[Sam Johnston]

On Wed, May 13, 2009 at 4:16 PM, Richard Davies <
richard.davies at elastichosts.com> 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!
>

Good work so far, thanks.


> 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.
>

Networks and storage can attach to networks remember. +1 for generic links.

Internet could be a well known UUID, but may be better not to specify as
there are different "types" of internet (fast, slow, filtered, unfiltered,
etc.). I know this was something I suggested myself but i'm not sure it
pulls its weight... maybe it does... at least it should be optional (think
offline setups).


> 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.
>

Ok be sure to include IPv6 addresses though. Oh, and IPX/SPX since we've got
an old novell server. And appletalk... you get the point. While we're there
I guess we should make storage LUNs first class citizens too. How about
compute peripherals?

Obviously I'm joking - IPs belong to networks and thus should hang off
networks. Need a "type" attribute for ipv4, ipv6, ipx/spx, etc.

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.
>

I'm happy with a combination... it makes sense to set "dhcp: true" on a
network segment but it makes more sense to configure an advanced application
level firewall (like a Netscaler
VPX<http://www.citrix.com/English/ps2/products/feature.asp?contentID=1689968>)
as a compute resource. Bonus points for being able to supply the device
configuration via OCCI (*cough*XML*cough*). Firewall rules should probably
be associated with a specific network connection, which may be non-trivial
but increasingly relevant/important (devices should have no access by
default when introduced and anything from pinholes to application level
firewalls applied thereafter).


> 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.)


Definitely, but this should make sense for the device - your eth0 is my en0
is his "Local Area Connection" and for network devices you have stuff like
"1/1". We don't care - add it as an attribute and forget about it.


> - Port firewalling rules (e.g. connect server to the internet network, but
> only
>  allow port 80 inbound)


We don't need to specify it, but we should consider it something someone
will have to implement in due course.


> - 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)


Ditto. This configuration could be arbitrarily complex (specifying HTTP
verbs, URL regexps, etc.) and is probably device dependent at least until
standardised. Yet another place where embedding/linking arbitrary content
types will be required.


> - 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).
>

Hmm... sounds unnecessary. Once you've assigned an IP to a server if you
want to make life easier by offering it over DHCP then go right ahead... I
don't see the use case otherwise.


> I think that all of these are best implemented as attributes on the link.
>

Yup, and more.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/dce53321/attachment.html