<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ian,<br>
Could you unlock your doc at <a moz-do-not-send="true"
href="https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs">https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs</a>?<br>
It require a permission to read.<br>
Thanks<br>
Yi<br>
<br>
<div class="moz-cite-prefix">On 12/18/13, 4:20 AM, Ian Wells wrote:<br>
</div>
<blockquote
cite="mid:CAPoubz7gWC5kkj+an_6eZsG59i4xr216g6wwwxAy6Hd7um=j-Q@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>A Neutron network is analagous to a wire between
ports. We can do almost everything with this wire - we
can pass both IP and non-IP traffic, I can even pass MPLS
traffic over it (yes, I tried). For no rational reason,
at least if you live north of the API, I sometimes can't
pass VLAN traffic over it. You would think this would be
in the specification for what a network is, but as it
happens I don't think we have a specification for what a
network is in those terms.<br>
<br>
I have a counterproposal that I wrote up yesterday [1].
This
is the absurdly simple approach, taking the position that
implementing trunks *should* be easy. That's actually not
such a bad position to take, because the problem lies with
certain plugins (OVS-based setups, basically) - it's not a
problem with Neutron.<br>
<br>
It's very uncompromising, though - it just allows you to
request a VLAN-clean network. It would work with OVS code
because it allows plugins to decline a request, but it
doesn't solve the VLAN problem for you, it just ensures
that you don't run somewhere where your application
doesn't work, and gives plugins with problems an
opportunity for special case code. You could expand it so
that you're requesting either a VLAN-safe network or a
network that passes *specified* VLANs - which is the
starting position of Eric's document, a plugin-specific
solution to a plugin-specific problem.<br>
<br>
</div>
I accept that, for as long as we use VLAN based
infrastructure, we have to accommodate the fact that VLANs
are a special case, but this is very much an artifact of the
plugin implementation - Linux bridge based network
infrastructure simply doesn't have this problem, for
instance.<br>
<br>
On 17 December 2013 06:17, Isaku Yamahata <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:isaku.yamahata@gmail.com" target="_blank">isaku.yamahata@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">- 2 Modeling proposal<br>
What's the purpose of trunk network?<br>
Can you please add a use case that trunk network can't
be optimized away?<br>
</blockquote>
<div><br>
</div>
<div>Even before I read the document I could list three use
cases. Eric's covered some of them himself.<br>
<br>
</div>
<div>The reasons you might want to have a trunked network
passing VLAN traffic:<br>
</div>
<div>1: You're replicating a physical design for simulation
purposes [2] <br>
<br>
2: There are any number of reasons to use VLANs in a
physical design, but generally it's a port reduction
thing. In Openstack, clearly I can do this a different
way - instead of using 30 VLANs over one network with two
ports, I can use 30 networks with two ports each. Ports
are cheaper when you're virtual, but they're not free -
KVM has a limitation of, from memory, 254 ports per VM.
So I might well still want to use VLANs. I could
arbitrarily switch to another encap technology, but this
is the tail wagging the dog - I have to change my design
because Neutron's contract is inconsistent.<br>
</div>
<div><br>
</div>
<div>3: I want to condense many tenant networks into a
single VM or physical box because I'm using a single VM to
offer logically separated services to multiple tenants.
This has all the points of (2) basically, that VLANs are
not the only encap I could use, but they're the
conventional one and widely supported. Provider networks
do actually offer the functionality you need for this
already - if you're talking physical - but they would, I
think, be awkward to use in practice, and they would eat
NIC ports on your hosts.<br>
</div>
<div><br>
</div>
-- <br>
<div>Ian.<br>
<br>
[1] <a moz-do-not-send="true"
href="https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs">https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs</a><br>
</div>
<div>[2] <a moz-do-not-send="true"
href="http://blogs.cisco.com/wp-content/uploads/network1-550x334.png">http://blogs.cisco.com/wp-content/uploads/network1-550x334.png</a>
- a network simulator (search for 'Cisco VIRL'). Shameless
plug, sorry, but it's an Openstack based application and
I'm rather proud of it.<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>