
Morning all, I've been doing some more work on the draft over the weekend and today as I hope to have it in good condition in time for the various cloud interop events next week. It's finally starting to take shape now that extensions (e.g. state machines), attributes and registries (e.g. HTTP status codes) have been added, even if they're a long way from finished. The OCCI Core profile is generic and can be used with any resource, while OCCI Infrastructure defines compute, network and storage nouns (with attributes that are designed to be both extensible and trivially mapped to txt, json and xml formats) as well as extensions for relevant functionality like state machines. Anyway the GridForge subversion repository just blew up and my local version doesn't build any more so given it's after 4am already I'm going to call it a day and send what I have so far by mail (attached). The master's DocBook v5 but there's HTML, XML-FO and PDF renderings too... I'll fix the subversion repository tomorrow so others can get in on the action. If you do plan to contribute though, please bear in mind that I am making personal contributions available under CC-BY-SA in addition to the standard OGF terms which I consider far too restrictive. I'd very much rather other editors follow my example so as the spec is not inextricably bound to any single organisation, as is customary for other cloud APIs (e.g. GoGrid, Sun Cloud API). Thanks, Sam

Great doc Sam !!! -gary Sam Johnston wrote:
Morning all,
I've been doing some more work on the draft over the weekend and today as I hope to have it in good condition in time for the various cloud interop events next week. It's finally starting to take shape now that extensions (e.g. state machines), attributes and registries (e.g. HTTP status codes) have been added, even if they're a long way from finished.
The OCCI Core profile is generic and can be used with any resource, while OCCI Infrastructure defines compute, network and storage nouns (with attributes that are designed to be both extensible and trivially mapped to txt, json and xml formats) as well as extensions for relevant functionality like state machines.
Anyway the GridForge subversion repository just blew up and my local version doesn't build any more so given it's after 4am already I'm going to call it a day and send what I have so far by mail (attached). The master's DocBook v5 but there's HTML, XML-FO and PDF renderings too... I'll fix the subversion repository tomorrow so others can get in on the action.
If you do plan to contribute though, please bear in mind that I am making personal contributions available under CC-BY-SA in addition to the standard OGF terms which I consider far too restrictive. I'd very much rather other editors follow my example so as the spec is not inextricably bound to any single organisation, as is customary for other cloud APIs (e.g. GoGrid, Sun Cloud API).
Thanks,
Sam
------------------------------------------------------------------------
OGF OCCI-WG Deliverables
OCCI-WG
May 2009
------------------------------------------------------------------------
OCCI Core
------------------------------------------------------------------------
Introduction
The Open Cloud Computing Interface is an open community consensus API, initially targeting cloud infrastructure services or "Infrastructure as a Service (IaaS)". A "Resource Oriented Architecture (ROA)", it is as close as possible to the underlying HyperText Transfer Protocol (HTTP), deviating only where absolutely necessary. Each resource (identified by a canonical URL) can have multiple representations which may or may not be hypertext (e.g. HTML). Metadata including associations between resources is exposed via HTTP headers (e.g. the Link: header), except in the case of collections where Atom is used as the meta-model.
Basics
URL Namespace
A single URL entry point (and optionally, suitable credentials for HTTP based authentication schemes) is all a client requires. Each resource type or "noun" (e.g. compute, network, storage) is visible as a collection at the root level (e.g. http://example.com/compute)/Perhaps we should consider allowing them anywhere/everywhere as is the case today/ and the resources themselves appear under these collections (e.g. http://example.com/compute/123). Implementors should also expose an AtomPub service document at the root to enable enumeration of resource types, supported formats and categories.
Nouns, Verbs and Attributes
Interfaces expose "nouns" which have "attributes" and on which "verbs" can be performed. The attributes are exposed as key-value pairs and appropriate verbs as links, following HATEOAS principles.
CRUD Operations
Create, Retrieve, Update and Delete (CRUD) operations map to the POST, GET, PUT and DELETE HTTP verbs respectively. HEAD and OPTIONS verbs may be used to retrieve metadata and valid operations without the entity body to improve performance. Additionally, all existing HTTP functionality is available for caching, proxying, gatewaying and other advanced functionality.
POST (Create)
POSTing a representation (e.g. OVF) to a collection (e.g. /compute) will result in a new resource being created (e.g. /compute/123) and returned in the Location: header. POST is also used with HTML form data to trigger verbs (e.g. restart)
GET (Retrieve)
GETting a resource (e.g. /compute/123) will return a representation of that resource in the most appropriate supported format specified by the client in the Accept header. Otherwise "406 Not Acceptable" will be returned.
PUT (Update)
PUTting a representation (e.g. OVF) to a URL (e.g. /compute/123) will result in the resource being created or updated. The URL is known or selected by the client (in which case UUIDs should be used), in contrast to POSTs where the URL is selected by the server.
DELETE (Delete)
DELETE results in the deletion of the resource (and everything "under" it, as appropriate).
Web Linking
Linked cloud resources extend the World Wide Web (WWW) of linked hypertext (e.g. HTML) documents, only the links themselves are expressed out-of-band rather than inline.
Collections
Operations that return multiple resources (e.g. categories, searches) are rendered as an Atom feed with an Atom entry per resource. Metadata that would normally appear in the HTTP headers appears in standard Atom elements with the entity-body itself being passed by reference or by value in the Atom content element.
Versioning
Clients and servers should expose the protocol version (e.g. OCCI/1.0) via the User-Agent and Server HTTP headers respectively. Should second or subsequent versions of the descriptor format be required the version will be added to the Internet media type (e.g. application/occi2+xml).
References
The following standards are referenced by this implementation.
*
RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1
*
RFC 4287 The Atom Syndication Format
*
RFC 5023 The Atom Publishing Protocol
Additionally RFC 2119 Requirement Levels are used throughout.
OCCI Infrastructure
------------------------------------------------------------------------
OCCI Infrastructure defines three nouns and various extensions relating to management of cloud infrastructure services (IaaS).
Nouns
Cloud infrastructure can be modeled using three primary nouns: compute, network and storage.
Compute
A compute resource is capable of conducting computations (e.g. a virtual machine).
*Table 1. Compute Attributes*
Attribute Type Description occi.compute.arch Enum (x86, x64) CPU Architecture (e.g. x64) occi.compute.cores Integer Number of CPU cores (e.g. 1, 2) occi.compute.memory Float (2^20 bytes) RAM in megabytes (e.g. 2048) occi.compute.speed Float (10^9 Hertz) Clock speed in gigahertz (e.g. 2.4)
Network
A network resource is capable of transferring data (e.g. a virtual network or VLAN).
*Table 2. Network Attributes*
Attribute Type Description occi.network.vlan-id Integer (0..4095) 802.1q VLAN ID (e.g. 4095) occi.network.vlan-tag Token Tag based VLANs (e.g. external-dmz) occi.network.ipv4[].gateway IPv4 Address IPv4 gateway address (e.g. 192.168.0.1) occi.network.ipv4[].netmask IPv4 Address IPv4 netmask address (e.g. 255.255.255.0) occi.network.ipv4[].network IPv4 Address IPv4 network address (e.g. 192.168.0.0) occi.network.ipv4[].cidr Integer (0..32) Netmask in CIDR notation (e.g. 24)
Storage
A storage resource is capable of mass storage of data (e.g. a virtual hard drive).
*Table 3. Storage Attributes*
Attribute Type Description occi.storage.persistence Enum (transient, persistent, reliable) Qualitative device persistence (e.g. transient) occi.storage.size Integer (10^9 bytes) Drive size in gigabytes (e.g. 40)
Extensions
Various extensions provide for more advanced management functionality such as billing, monitoring and reporting.
State machine (state)
The state machine extension allows for the modeling of arbitrarily complex state machines and associated transitions (e.g. start, stop, restart).
OCCI Registries
------------------------------------------------------------------------
*Table 1. HTTP Status Codes*
Code Description Example 200 OK Request completed successfully Response is returned 201 Created Request completed successfully, resource was created Pointer to new resource returned 202 Accepted Request accepted, processing not completed Workload starting but not yet active 301 Moved Permanently Resource has been assigned a new permanent URI Workload migrated to another installation 302 Found Resource resides temporarily under a different URI Alias pointing to UUID can be updated 304 Not Modified Conditional GET on resource that is unchanged Client already has the latest version of the resource 400 Bad Request Request could not be understood by the server due to malformed syntax Client sent a representation that was unable to be understood 401 Unauthorized The request requires user authentication Client must retry with authentication 402 Payment Required The server has refused to fulfill the request Credit limit exceeded 403 Forbidden The server understood the request, but is refusing to fulfill it Attempt to access resource without permission 404 Not Found The server has not found the resource Feed or entry unknown 405 Method Not Allowed The method specified is not allowed for the resource Attempt to delete an immutable resource 406 Not Acceptable The resource is not capable of requested content characteristics Unsupported output format requested 409 Conflict Request is in conflict with the current state of the resource Resource updated by a third-party in the interim 410 Gone Resource is gone, no forwarding address Resource was deleted 500 Internal Server Error Server encountered an unexpected condition An unknown failure has occurred (e.g. out of memory) 501 Not Implemented Functionality required to fulfill request is not implemented A missing extension was called 502 Bad Gateway An invalid response was received from an upstream server The gateway received a malformed response from a node 503 Service Unavailable Server is temporarily unable to handle the request Server may be overloaded or down for maintenance 504 Gateway Timeout No response was received from an upstream server The gateway did not receive a response within the timeout period
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

Hi, Sam. Very clear document. Thanks for getting this together. I noticed that the storage noun is related to mountable storage. Forgive me, if I missed the discussion. What is the status of object storage (ex. Amazon S3)? I'm currently working on cloud object storage interop in jclouds. I'd expect something like the following, if we aren't deferring this service to extensions: Object Storage An object storage resource is capable of mass, and potentially limitless storage of key, value pairs. *Table 3. Storage Attributes* AttributeTypeDescriptionocci.objectstorage.publicBoolean (true,false) Expose objects without access controls occi.objectstorage.cnameStringcname that identifies global namespace What are your thoughts? Regards, -Adrian jclouds http://code.google.com/p/jclouds http://anyweight.blogspot.com/ On Tue, Jul 7, 2009 at 5:25 AM, Sam Johnston <samj@samj.net> wrote:
Morning all,
I've been doing some more work on the draft over the weekend and today as I hope to have it in good condition in time for the various cloud interop events next week. It's finally starting to take shape now that extensions (e.g. state machines), attributes and registries (e.g. HTTP status codes) have been added, even if they're a long way from finished.
The OCCI Core profile is generic and can be used with any resource, while OCCI Infrastructure defines compute, network and storage nouns (with attributes that are designed to be both extensible and trivially mapped to txt, json and xml formats) as well as extensions for relevant functionality like state machines.
Anyway the GridForge subversion repository just blew up and my local version doesn't build any more so given it's after 4am already I'm going to call it a day and send what I have so far by mail (attached). The master's DocBook v5 but there's HTML, XML-FO and PDF renderings too... I'll fix the subversion repository tomorrow so others can get in on the action.
If you do plan to contribute though, please bear in mind that I am making personal contributions available under CC-BY-SA in addition to the standard OGF terms which I consider far too restrictive. I'd very much rather other editors follow my example so as the spec is not inextricably bound to any single organisation, as is customary for other cloud APIs (e.g. GoGrid, Sun Cloud API).
Thanks,
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

On Tue, Jul 7, 2009 at 7:13 AM, Adrian Cole <adrian@jclouds.org> wrote:
Very clear document. Thanks for getting this together.
No problem - I'll be working on it all week with a view to having something to show next week so now's the time to give feedback and/or get involved.
I noticed that the storage noun is related to mountable storage. Forgive me, if I missed the discussion. What is the status of object storage (ex. Amazon S3)? I'm currently working on cloud object storage interop in jclouds. I'd expect something like the following, if we aren't deferring this service to extensions:
<snip>
What are your thoughts?
Object storage (databases), queues and other programmer constructs are not what I would consider cloud infrastrucutre services (IaaS), rather cloud platform services (PaaS) and as such out of scope *for now*. That said, you'll see that I have meticulously separated generic requirements into the OCCI Core profile (with the exception of a few examples) and am keeping all the IaaS stuff in the OCCI Infrastructure profile (which you'll see are actually separate DocBook "article<http://www.docbook.org/tdg/en/html/article.html> "s). That way, if you want to expose other resources (platforms, applications or even things like contacts, calendar entries, etc.) then you can always do so on top of OCCI Core. It also paves the way for us to create an OCCI Platform profile once we're done with IaaS - I'm already thinking about how this might look... Sam

I think that object storage is out of scope IMHO. It deserves a separate API. --Randy On Jul 6, 2009, at 10:13 PM, Adrian Cole wrote:
Hi, Sam.
Very clear document. Thanks for getting this together.
I noticed that the storage noun is related to mountable storage. Forgive me, if I missed the discussion. What is the status of object storage (ex. Amazon S3)? I'm currently working on cloud object storage interop in jclouds. I'd expect something like the following, if we aren't deferring this service to extensions:
Object Storage
An object storage resource is capable of mass, and potentially limitless storage of key, value pairs.
Table 3. Storage Attributes
Attribute Type Description occi.objectstorage.public Boolean (true,false) Expose objects without access controls occi.objectstorage.cname String cname that identifies global namespace
What are your thoughts?
Regards, -Adrian
jclouds http://code.google.com/p/jclouds http://anyweight.blogspot.com/
On Tue, Jul 7, 2009 at 5:25 AM, Sam Johnston <samj@samj.net> wrote: Morning all,
I've been doing some more work on the draft over the weekend and today as I hope to have it in good condition in time for the various cloud interop events next week. It's finally starting to take shape now that extensions (e.g. state machines), attributes and registries (e.g. HTTP status codes) have been added, even if they're a long way from finished.
The OCCI Core profile is generic and can be used with any resource, while OCCI Infrastructure defines compute, network and storage nouns (with attributes that are designed to be both extensible and trivially mapped to txt, json and xml formats) as well as extensions for relevant functionality like state machines.
Anyway the GridForge subversion repository just blew up and my local version doesn't build any more so given it's after 4am already I'm going to call it a day and send what I have so far by mail (attached). The master's DocBook v5 but there's HTML, XML-FO and PDF renderings too... I'll fix the subversion repository tomorrow so others can get in on the action.
If you do plan to contribute though, please bear in mind that I am making personal contributions available under CC-BY-SA in addition to the standard OGF terms which I consider far too restrictive. I'd very much rather other editors follow my example so as the spec is not inextricably bound to any single organisation, as is customary for other cloud APIs (e.g. GoGrid, Sun Cloud API).
Thanks,
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com

I do want to clarify that I think that eventually an extension to OCCI that allows integrating backends would be very useful. Like the ability to pass in an object store URL and specify that meta-data should be pulled from it, or an object should be stored onto a disk prior to initial bootup. Those would be very powerful possibilities. Thanks, --Randy Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com

Thanks for the feedback, Randy. I'll take this offline for now. As I mentioned, I'm working on object storage portability from a java client perspective. If anyone would like to be involved, please do drop me a line. Cheers, -Adrian jclouds <http://code.google.com/p/jclouds> On Tue, Jul 7, 2009 at 9:51 PM, Randy Bias <randyb@neotactics.com> wrote:
I do want to clarify that I think that eventually an extension to OCCI that allows integrating backends would be very useful. Like the ability to pass in an object store URL and specify that meta-data should be pulled from it, or an object should be stored onto a disk prior to initial bootup. Those would be very powerful possibilities.
Thanks,
--Randy
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.comBLOG: http://cloudscaling.com

This is an interesting point. There is a definite disconnect with the level of services between networking and storage. In the network model, we are assigning IP addresses that are normally instantiated in the OS network stack, not the VM infrastructure per se. If the OS doesn't use IP, it uses ATM or IB, the IP address is valueless. However a MAC address, which we are not supporting at the moment, is more applicable and insulated from transport protocol implementations. . As functional equivalents in the storage world, an IP address would be on the same level as a controller/target/LUN (ctl). Unfortunately, VMs like to implant storage at dsk device, locating the storage much higher up the storage stack than IP address equivalence. I strongly believe that a source URI is required to identify the origin data storage. This is no different than defining an IP gateway. The spec does include extensible capabilities though linking, as very powerful feature. If a provider wants to include SNIA, native definitions or custom, it can easily be achieved. -gary Randy Bias wrote:
I do want to clarify that I think that eventually an extension to OCCI that allows integrating backends would be very useful. Like the ability to pass in an object store URL and specify that meta-data should be pulled from it, or an object should be stored onto a disk prior to initial bootup. Those would be very powerful possibilities.
Thanks,
--Randy
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com <mailto:randyb@neotactics.com> BLOG: http://cloudscaling.com
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

"Adrian" == Adrian Cole <adrian@jclouds.org> writes: Adrian> I noticed that the storage noun is related to mountable Adrian> storage. Forgive me, if I missed the discussion. What is Adrian> the status of object storage (ex. Amazon S3)? I'm Adrian> currently working on cloud object storage interop in Adrian> jclouds. I'd expect something like the following, if we Adrian> aren't deferring this service to extensions:
I understand your interest and concern. I'm not entirely sure S3-like storage is in scope at this point in the game. I don't think I can boot a VM from it yet. (Amazon EBS clearly is in scope) -- ] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy"); [

Question about the Network Attributes table: occi.network.ipv4[].gateway Does the [] represent array indexation? If so, are the indexes designated by the occi.network.vlan-id ? .. Shlomo

Hi Shlomo, On Tue, Jul 7, 2009 at 9:49 AM, <shlomo.swidler@gmail.com> wrote:
Question about the Network Attributes table:
occi.network.ipv4[].gateway
Does the [] represent array indexation? If so, are the indexes designated by the occi.network.vlan-id ?
Yes and no (in that order). The 802.1q vlan-id is an optional parameter that specifies one way for the virtual network should be connected to the real world. The indexes are natural for json and xml but less so for text... thinking something like: TXT: occi.network.ipv4[0].gateway = 192.168.0.1 JSON: { "occi": { "network": { "ipv4: [ { "gateway": "192.168.0.1" XML: <occi> <network> <ipv4> <gateway>192.168.0.1</gateway> Sam

Ah, got it. The [] designation just indicates that the occi.network.ipv4 element represents a collection. The specific addressing mechanism for elements in the collection is rendering-specific. Thanks. On Tue, Jul 7, 2009 at 1:10 PM, Sam Johnston<samj@samj.net> wrote:
Hi Shlomo,
On Tue, Jul 7, 2009 at 9:49 AM, <shlomo.swidler@gmail.com> wrote:
Question about the Network Attributes table:
occi.network.ipv4[].gateway
Does the [] represent array indexation? If so, are the indexes designated by the occi.network.vlan-id ?
Yes and no (in that order). The 802.1q vlan-id is an optional parameter that specifies one way for the virtual network should be connected to the real world. The indexes are natural for json and xml but less so for text... thinking something like:
TXT: occi.network.ipv4[0].gateway = 192.168.0.1
JSON: { "occi": { "network": { "ipv4: [ { "gateway": "192.168.0.1"
XML: <occi> <network> <ipv4> <gateway>192.168.0.1</gateway>
Sam

We may want to consider 2 additional properties for storage. Name: It is used to identify the storage object MountPoint: It is used to identify the storage object presentation to the OS These are very rough equivalents to vlan and IP address respectively... -gary shlomo.swidler@gmail.com wrote:
Ah, got it. The [] designation just indicates that the occi.network.ipv4 element represents a collection. The specific addressing mechanism for elements in the collection is rendering-specific.
Thanks.
On Tue, Jul 7, 2009 at 1:10 PM, Sam Johnston<samj@samj.net> wrote:
Hi Shlomo,
On Tue, Jul 7, 2009 at 9:49 AM, <shlomo.swidler@gmail.com> wrote:
Question about the Network Attributes table:
occi.network.ipv4[].gateway
Does the [] represent array indexation? If so, are the indexes designated by the occi.network.vlan-id ?
Yes and no (in that order). The 802.1q vlan-id is an optional parameter that specifies one way for the virtual network should be connected to the real world. The indexes are natural for json and xml but less so for text... thinking something like:
TXT: occi.network.ipv4[0].gateway = 192.168.0.1
JSON: { "occi": { "network": { "ipv4: [ { "gateway": "192.168.0.1"
XML: <occi> <network> <ipv4> <gateway>192.168.0.1</gateway>
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

On Tue, Jul 7, 2009 at 12:53 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
We may want to consider 2 additional properties for storage.
Name: It is used to identify the storage object
title and summary information (as well as categories) will be common to all objects - I'll add it to OCCI core directly.
MountPoint: It is used to identify the storage object presentation to the OS
These are very rough equivalents to vlan and IP address respectively...
Right, which brings us back to links and associations (remember, mount points and so on are not related to resources but to the links between them). I've been working hard on these, looking at details like caching and capacity and will document my findings as soon as I work out wtf is up with subversion. Sam

On Tue, Jul 7, 2009 at 12:27 PM, <shlomo.swidler@gmail.com> wrote:
Ah, got it. The [] designation just indicates that the occi.network.ipv4 element represents a collection. The specific addressing mechanism for elements in the collection is rendering-specific.
Yeah, why anyone would want two subnets on the same segment I'm not really sure, but I've seen it done and it doesn't cost much to support.
Thanks.
Note also the reappearance of the vlan tags we discussed at the outset - basically 802.1q but text based (e.g. "internet" vs "dmz" vs "mylan"). Sam
Hi Shlomo,
On Tue, Jul 7, 2009 at 9:49 AM, <shlomo.swidler@gmail.com> wrote:
Question about the Network Attributes table:
occi.network.ipv4[].gateway
Does the [] represent array indexation? If so, are the indexes designated by the occi.network.vlan-id ?
Yes and no (in that order). The 802.1q vlan-id is an optional parameter
On Tue, Jul 7, 2009 at 1:10 PM, Sam Johnston<samj@samj.net> wrote: that
specifies one way for the virtual network should be connected to the real world. The indexes are natural for json and xml but less so for text... thinking something like:
TXT: occi.network.ipv4[0].gateway = 192.168.0.1
JSON: { "occi": { "network": { "ipv4: [ { "gateway": "192.168.0.1"
XML: <occi> <network> <ipv4> <gateway>192.168.0.1</gateway>
Sam

There are valid reasons for doing this. I've done it in the past and I'm sure there will be a need in the future. --Randy On Jul 7, 2009, at 5:02 AM, Sam Johnston wrote:
Yeah, why anyone would want two subnets on the same segment I'm not really sure, but I've seen it done and it doesn't cost much to support.
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com

"Sam" == Sam Johnston <samj@samj.net> writes: >> Ah, got it. The [] designation just indicates that the >> occi.network.ipv4 element represents a collection. The specific >> addressing mechanism for elements in the collection is >> rendering-specific. >>
Sam> Yeah, why anyone would want two subnets on the same segment I'm Sam> not really sure, but I've seen it done and it doesn't cost much Sam> to support. Maybe it matters less in the cloud where network interfaces are all virtual, and so it's easy to have more than one... however, in the physical world, you sometimes get subnets that are non-aggregatable (usually because you got additional allocation from ARIN/ISP/etc.), and you want to run things such that they all are on the same physical network. In Linux-speak, this means you do something like: ip addr add 3.4.5.6/24 dev eth0 ip route add 1.2.3.0/24 dev eth0 You can do similar things on *BSD, and Windows seems to do this by mistake regularly. If you don't do this, then you wind up going through your router, which probably has multiple aliases on the two subnets, but that may cost you performance, and it may also cost you bandwidth charges. -- ] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy"); [

"Sam" == Sam Johnston <samj@samj.net> writes: >> Ah, got it. The [] designation just indicates that the >> occi.network.ipv4 element represents a collection. The specific >> addressing mechanism for elements in the collection is >> rendering-specific. >>
Sam> Yeah, why anyone would want two subnets on the same segment I'm Sam> not really sure, but I've seen it done and it doesn't cost much Sam> to support. Maybe it matters less in the cloud where network interfaces are all virtual, and so it's easy to have more than one... however, in the physical world, you sometimes get subnets that are non-aggregatable (usually because you got additional allocation from ARIN/ISP/etc.), and you want to run things such that they all are on the same physical network. In Linux-speak, this means you do something like: ip addr add 3.4.5.6/24 dev eth0 ip route add 1.2.3.0/24 dev eth0 You can do similar things on *BSD, and Windows seems to do this by mistake regularly. If you don't do this, then you wind up going through your router, which probably has multiple aliases on the two subnets, but that may cost you performance, and it may also cost you bandwidth charges. -- ] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] h("Just another Debian GNU/Linux using, kernel hacking, ruby guy"); [

On Tue, Jul 7, 2009 at 11:36 PM, Michael Richardson <mcr@sandelman.ca>wrote:
Maybe it matters less in the cloud where network interfaces are all virtual, and so it's easy to have more than one... however, in the physical world, you sometimes get subnets that are non-aggregatable (usually because you got additional allocation from ARIN/ISP/etc.), and you want to run things such that they all are on the same physical network. In Linux-speak, this means you do something like: ip addr add 3.4.5.6/24 dev eth0 ip route add 1.2.3.0/24 dev eth0
Actually now that you mention it I did similar things in a former life as a sysadmin... I'd written a kernel module for network quotas<http://svn.netfilter.org/netfilter/branches/patch-o-matic-ng/linux-2.6.11/quota/linux-2.6/net/ipv4/netfilter/ipt_quota.c>and some of the sites had overlapping subnets for admin vs student machines. So we'll leave it there for now in case someone wants to conduct similar (virtual) evil. Sam

One use case I've seen is IP block migration. For example, you're renumbering from 1.1.1.1/24 into 2.2.2.2/24 and aren't moving the servers. It can be useful to keep both blocks on the network segment simultaneously for a while. --Randy On Jul 7, 2009, at 3:13 PM, Sam Johnston wrote:
On Tue, Jul 7, 2009 at 11:36 PM, Michael Richardson <mcr@sandelman.ca> wrote: Maybe it matters less in the cloud where network interfaces are all virtual, and so it's easy to have more than one... however, in the physical world, you sometimes get subnets that are non-aggregatable (usually because you got additional allocation from ARIN/ISP/etc.), and you want to run things such that they all are on the same physical network. In Linux-speak, this means you do something like: ip addr add 3.4.5.6/24 dev eth0 ip route add 1.2.3.0/24 dev eth0
Actually now that you mention it I did similar things in a former life as a sysadmin... I'd written a kernel module for network quotas and some of the sites had overlapping subnets for admin vs student machines.
So we'll leave it there for now in case someone wants to conduct similar (virtual) evil.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
participants (7)
-
Adrian Cole
-
Gary Mazz
-
Michael Richardson
-
Michael Richardson
-
Randy Bias
-
Sam Johnston
-
shlomo.swidler@gmail.com