The network range was put in place to support as part of a provisioning scheme used by some cloud providers. The range was intended to select a subset of a network segment, much like the client auto-configuring DHCP. The provider responds with one arbitrary IP address bounded by the range value.

Under this scheme, if you needed a network interface with a different gateway address, you requested a different network Resource (NIC) .

-gary

On 11/8/2010 5:04 AM, Edmonds, AndrewX wrote:

Address ranges - good catch on this one Csom :-) - yes this should only be 
0...1
On other aspects I would agree with what Ralf has said.

Andy

-----Original Message-----
From: Ralf Nyren [mailto:ralf@nyren.net]
Sent: Monday, November 08, 2010 12:00 PM
To: Csom Gyula; Edmonds, AndrewX; occi-wg@ogf.org
Subject: Re: [occi-wg] Infrastructure Document

inline..

On Sat, 06 Nov 2010 08:23:13 +0100, Csom Gyula <csom@interface.hu> wrote:

Extensions would do the home work:) Meanwhile for the long term I would
propose the following approach.

Some programming languages provides a so called standard library besides
the
core. I think a similar solution could work here as well. That is
typical extensions
those applicable to many situations but not all, could be covered by
OCCI:
maybe not in the core but in a standard "library", maybe not in the next
release
but in a later one.

Yes, good point. The plan is to have multiple extensions available for
different use cases etc. However, this will have to wait to a future
release of OCCI.

Regarding DHCP... an occi.ipnetwork.dhcp could be the additional
attribute. Like
occi.ipnetwork.gateway it would hold an IP address, namely the address
of the
DHCP server. This would support only one goal: to tell the cloud that
this
address is reserved in the range:

available addresses := occi.ipnetwork.address(es) -
occi.ipnetwork.gateway - occi.ipnetwork.dhcp

But maybe I missunderstood the role of occi.ipnetwork.address:

- The spec says: "IPv4 or IPv6 Address range, CIDR notation", so I
thought it
  was something like this: 192.168.1.0/24 would define a C class subnet
with 256
  addresses.
  If this is the case than there is a need for a method to specify
reserved
  addresses within the range. Gateway is a sample for such a reserved
address
  but others could be there as wll (like DHCP if it is different from
the gw).

- The spec also says that multiplicity is 0..* so maybe one can define
many
  addresses, but cannot specify a whole range. That is she should list
avalailable
  addresses one by one.
  If this is the case then there is no need for the suggested attribute.
One could
  simply exlude the reserved addresses from the range.

So my question is: Could you please clarify the occi.ipnetwork.address
semantics?
in respect of (a) address ranges vs. individual addresses and (b)
reserved
addresses?

Ah, I see your issue now. Hmm... having multiple address ranges and just
one gateway does not make sense. Each CIDR range need its own gateway to
be useful. Andy, do you remember the reason behind this?

Regarding reserved addresses I think this is something for the server
side. If you need a dhcp server address just don't make that address
available for allocation. I may be wrong but why would the client need to
know about reserved addresses?

regards, Ralf


-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg