<div dir="ltr">Hi Stephen,<div><br></div><div>A couple of inline comments:</div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><ul><ul><li><br>BBG proposal just has attributes for both and IPv4 address and an IPv6 address in its "VIP" object. (Meaning it's slightly different than a "VIP" as people are likely to assume what that term means.)</li>
</ul></ul></div></div></blockquote><div>This is a correct approach. VIP has single neutron port, which however may have ip address on several subnets at once, so ipv4+ipv6 is easily solved within 1 VIP.</div><div>I think that's a preferred way.<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><ul><ul>
<li><br></li></ul></ul></div><div><b>Maybe we should wait until the survey results are out?</b></div><div>No sense solving for use cases that nobody cares about, eh.</div><div><br></div><div><b>Maybe we should just look at the differences?</b></div>

<div>The core object models we've proposed are almost identical. Change the term "Listener" to "Load Balancer" in my model, and you've essentially got the same thing as the Rackspace model.</div>
</div></blockquote><div>I guess you meant VIP, not Listener.</div><div>I think what is more important is tree-like configuration structure.</div><div>However having Loadbalancer as the root object vs VIP has difference in meaning. Loadbalancer implies several L2 ports for the frontend (e.g. multiple VIPs with own ip addresses) while VIP implies only one L2 port.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>For example, I understand the Rackspace model is using a join object between "load balancer" and "vip" so these can have a n:m relationship-- and this is almost entirely to solve use case #14 in the document.</div>
</div></blockquote><div>This is clearly an overkill to share VIPs between loadbalancer instances.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><br></div>
<div><div><b>We need to decide what "load balancer" means and go that.</b></div></div><div>This has been something that's come up a lot, and the more we ignore it, it seems to me, the more it just adds to the confusion to the discussion.</div>

<div><br></div><div>Rackspace is defining a load balancer as:  <span style="background-color:transparent;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">An entity that contains multiple VIPs, but only one tcp/udp port and protocol (</span><a href="http://en.wikipedia.org/wiki/Load_balancing_%28computing%29" style="text-decoration:none" target="_blank"><span style="font-size:15px;font-family:Arial;background-color:transparent;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">http://en.wikipedia.org/wiki/Load_balancing_%28computing%29</span></a><span style="background-color:transparent;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">) . </span></div>
</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="background-color:transparent;font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">It may have a default pool (named just pool in API object).  It also may have a content switching object attached that defines L7 rules. </span></div>
</div></blockquote><div>I may have missed something, did you mean one tcp/upd port and protocol per VIP?  Or otherwise how is that possible?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div><div><b>What does "the root" mean when we're looking at an object graph, not a tree? Or maybe the people most likely to use the single-call interface should have the strongest voices in deciding where it should actually be placed?</b></div>

<div>I think probably the biggest source of contention over the API proposals thus far are what object should be considered the "root" of the tree.</div></div></div></blockquote><div>'root object'  has the sole purpose of transforming arbitrary graph of objects into a tree.</div>
<div>We can't move forward without properly defining it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div>This whole concept seems to strike me as odd-- because when you have a graph, even if it's somewhat tree-like (ie. there are leaf nodes), does the term "root" even apply? Can someone please tell me what criteria they're using when they say that one object should be a "root" and another should not?</div>
</div></div></blockquote><div>Criterias are:</div><div>- user can think of an object as representation of 'logical service instance' (logical loadbalancer)</div><div>- workflow starts with object creation</div><div>
- it makes sense to apply attributes like Flavor (service requirements) to it.</div><div><br></div><div>Thanks,</div><div>Eugene.</div></div><br></div></div>