[Capi-bof] Charter - last call for changes

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Sam" == Sam Johnston <samj at samj.net> writes:
    Sam> On Wed, Mar 25, 2009 at 2:18 PM, Michael Richardson
    Sam> <mcr at sandelman.ca>wrote:

    >> >>>>> "Sam" == Sam Johnston <samj at samj.net> writes:
    Sam> Aside from that the "network tag" suggestion I made before
    Sam> would allow for the creation of private networks (two
    Sam> interfaces with the same tag would obviously be wired together)
    Sam> but assigning meaning to those tags (subnet details, etc.)
    Sam> would be left to the fabric. The vast majority of workloads
    Sam> don't care, so long as they can talk to each other and their
    Sam> clients (assuming they have any which is not always the case).

    >> My kinds of deployments I need to do require multiple network
    >> interfaces per VM for security and performance reasons.
    >> Typically that means 4 networks, with one of those being the
    >> Internet.
    >> 
    >> An API that does not permit me to do describe this would not be
    >> useful to me.  I do not believe that this is a a difficult thing
    >> to accomplish, and I understand it to be in scope of the proposed
    >> charter.
    >> 

    Sam> Actually this approach does allow you do to do that - you could
    Sam> have an arbitrary number of interfaces and storage mounts. The
    Sam> question is how much you should be able to configure those
    Sam> resources.

  So, the number of network interfaces is in scope, and how they are
configured is in scope, and whether or not the virtual switch has CDP
enabled is possibly in scope (as a vendor extension).

    Sam> The question is, do we want to go down the path of
    Sam> configuration and if so how far, knowing that there is no end
    Sam> in sight (what about non-IP protocols?  IPv6? esoteric details
    Sam> like frame size?). And if we don't go far enough then will
    Sam> people implement it anyway, resulting in incompatible
    Sam> implementations?

  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.

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

iQEVAwUBScpOy4CLcPvd0N1lAQLYVwgAjvazux2swcERg4eE81trM4csO0oMPMvG
KMUzKq1BNq04S7NhuC/oe+QpBcrF3N2sub3CyHsrqsNmJ/7ORNQBgGgTvHdx43Sl
oiMo9CZmBdUKFw/H4oFqzZ9qW/Jp5O2ncZpd48nGHPC1O8nAtT+ZnfyKtX23bMdl
HQNmeNpRGcZt0n/MZixebEr9L7ZXS2VY6oCNXvg0OF6J4pYYVwsuFDdVYUUU1K3E
p269YjnVha/h0CN/wN0BC1WsIAX86GVhHEL6dc4L6QVFoTqjm5CEYKK2pBWxtSUP
oEEK/0oaQKJdh/KRRk/VUHHmPfcAX2NeltdFDLL+r6j9+DCMwUu3MA==
=swJU
-----END PGP SIGNATURE-----