[occi-wg] Networks: attributes and verbs

[Gary Mazz]

This is sounding awfully familiar, like DMTF's CIM model.  

How does this model handle channel bonding, cells, failover/failback, 
virtual circuits and traffic shaping ?

-gary

Sam Johnston wrote:
> On Wed, May 13, 2009 at 4:16 PM, Richard Davies 
> <richard.davies at elastichosts.com 
> <mailto: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
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>