[Capi-bof] Charter - last call for changes

[Sam Johnston]

On Wed, Mar 25, 2009 at 6:05 PM, Michael Richardson <
mcr at sandelman.ottawa.on.ca> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >>>>> "Sam" == Sam Johnston <samj at samj.net> writes:
>     >> I would suggest that layer-3 configuration is simply out of
>    >> scope.  Layer-3 configuration is not a problem unique to cloud
>    >> computing: a cabinet/bay full of servers has exactly the same
>    >> problems as a cloud of virtual machines.
>    >>
>    >> What is in scope layer-1 and layer-2 configuration, which
>    >> historically was physical, and therefore a "local consideration"
>    >> before.
>    >>
>
>     Sam> Actually layer 2 (data-link/MAC) is usually burnt into the VM
>
> What do you mean, "burnt into the VM"?
>

I mean included in the textual description/configuration of the virtual
machine which we were talking about being immutable.


> Lets take OVF for a moment. The macaddress of the adapter is NOT present
> there... I would like to be able to specify it to the cloud along with
> the OVF to use, or ask the cloud to allocate a unique one to this
> instance.
>

Actually it is in the OVF spec
(PDF<http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf>
):

*Address:* Device specific. For an Ethernet adapter, this specifies the MAC
address.

Another interesting parameter is Connection ("*For an Ethernet adapter, this
specifies the abstract network connection name for the virtual machine. All
Ethernet adapters that specify the same abstract network connection name
within an OVF package shall be deployed on the same network.*"). This is
pretty much exactly what I described independently before so it's good
confirmation that we're on the right track.

As for how IP is allocated, DHCP is certainly common, but that's a
> function of what's inside the VM.  It could also be statically defined.
>

I appreciate the utility for setting addresses (be they MACs or IPs) and
suspect the attribute approach I described before would be a sensible
solution, but it's something we can discuss in detail once the group is up
and running I think.


>    Sam> So what we're really talking about here is restricting this to
>    Sam> layer 1 (physical) - a virtual wiring cabinet of sorts. The
>    Sam> proposed tag option allows for arbitrarily complex
>    Sam> configurations (including vendor extensions for runtime
>    Sam> concerns like enabling CDP) - the only real remaining question
>    Sam> is whether it's interesting to allow multiple tags per
>    Sam> interface.
>
>    Sam> Does that all sit well with you? We agree that the workloads
>    Sam> are essentially immutable.
>
> I think we have a mild terminology confusion, but you have got my
> agreement to this charter.
>

Great, thanks.

Is there any other feedback?

Sam


> - --
> ]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security
> guy"); [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBScpkaYCLcPvd0N1lAQIRJwf/QoNfgVwl9NpC/s5JXxzL2bWQ833s1h/M
> dJvs7YVvA01GXBh/tLd55LYvUoXfU7QzseYSTsBMcIm1AguOdi0UoO2q7NaMT6Pd
> 7aNARE0JJv46tAyGSIrUDxrbmraS5lms/g7h2uOZf1tNEPu0JWBesvkfgNuoki7E
> alS0bLaz/Ag2xRDc/QmcTcDPfIP+Rm80cbigG2FXKaYmoqP3qujJVnvGZp58M105
> +ZV0DBcpZT9cpEzAFuRlz7ZAGMTJRehYKmNTFYwqrp52yhT+kf0WOxUAD4qDfAmr
> 5hDtfjZ+vyT3PAUt2/vx9mI3MlLAZ085vOATw/ovaQrh9zcKKfUIDQ==
> =2eob
> -----END PGP SIGNATURE-----
> _______________________________________________
> Capi-bof mailing list
> Capi-bof at ogf.org
> http://www.ogf.org/mailman/listinfo/capi-bof
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/capi-bof/attachments/20090326/62dac2c6/attachment.html