<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
p.msochpdefault, li.msochpdefault, div.msochpdefault
{mso-style-name:msochpdefault;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:10.0pt;
font-family:"Times New Roman","serif";}
span.emailstyle17
{mso-style-name:emailstyle17;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.emailstyle18
{mso-style-name:emailstyle18;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.balloontextchar0
{mso-style-name:balloontextchar;
font-family:"Tahoma","sans-serif";}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It sounds like this would match VLAN trunk.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Maybe it could be mapped to trunk port also, but I have not really worked with flat networks so I am not sure how DHCP etc. looks like.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Is it desired to be able to control port membership of VLANs or is it ok to connect all VLANs to all ports?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">/Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Wuhongning [mailto:wuhongning@huawei.com]
<br>
<b>Sent:</b> den 4 november 2014 03:41<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">Is the trunk port use case like the super vlan?
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">Also there is another typical use case maybe not covered: extended flat network. Traffic on the port carries multiple vlans, but these vlans are not necessarily
managed by neutron-network, so can not be classified to trunk port. And they don't need a gateway to communicate with other nodes in the physical provider network, what they expect neutron to do, is much like what the flat network does(so I call it extended
flat): just keep the packets as is bidirectionally between wire and vnic.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"><o:p> </o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:black">
<hr size="2" width="100%" align="center">
</span></div>
<div id="divRpF350933">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Erik Moe [erik.moe@ericsson.com]<br>
<b>Sent:</b> Tuesday, November 04, 2014 5:36 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints</span><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I created an etherpad and added use cases (so far just the ones in your email).</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><a href="https://etherpad.openstack.org/p/tenant_vlans" target="_blank">https://etherpad.openstack.org/p/tenant_vlans</a></span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">/Erik</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Erik Moe [<a href="mailto:erik.moe@ericsson.com">mailto:erik.moe@ericsson.com</a>]
<br>
<b>Sent:</b> den 2 november 2014 23:12<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints</span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Ian Wells [<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">mailto:ijw.ubuntu@cack.org.uk</a>]
<br>
<b>Sent:</b> den 31 oktober 2014 23:35<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black"><br>
On 31 October 2014 06:29, Erik Moe <<a href="mailto:erik.moe@ericsson.com" target="_blank">erik.moe@ericsson.com</a>> wrote:<o:p></o:p></span></p>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">I thought Monday network meeting agreed on that “VLAN aware VMs”, Trunk network + L2GW were different use cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Still I get the feeling that the proposals are put up against each other.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">I think we agreed they were different, or at least the light was beginning to dawn on the differences, but Maru's point was that if we really want to decide what specs we have we need
to show use cases not just for each spec independently, but also include use cases where e.g. two specs are required and the third doesn't help, so as to show that *all* of them are needed. In fact, I suggest that first we do that - here - and then we meet
up one lunchtime and attack the specs in etherpad before submitting them. In theory we could have them reviewed and approved by the end of the week. (This theory may not be very realistic, but it's good to set lofty goals, my manager tells me.)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ok, let’s try. I hope you theory turns out to be realistic.
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="color:black"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:black">Here are some examples why bridging between Neutron internal networks using trunk network and L2GW IMO should be avoided. I am still fine with bridging to external networks.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Assuming VM with trunk port wants to use floating IP on specific VLAN. Router has to be created on a Neutron network behind L2GW since Neutron router cannot handle VLANs. (Maybe not too common use case, but just
to show what kind of issues you can get into)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">The code to check if valid port has to be able to traverse the L2GW. Handing of IP addresses of VM will most likely be affected since VM port is connected to several broadcast domains. Alternatively new API can
be created.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Now, this is a very good argument for 'trunk ports', yes. It's not actually an argument against bridging between networks. I think the bridging case addresses use cases (generally
NFV use cases) where you're not interested in Openstack managing addresses - often because you're forwarding traffic rather than being an endpoint, and/or you plan on disabling all firewalling for speed reasons, but perhaps because you wish to statically configure
an address rather than use DHCP. The point is that, in the absence of a need for address-aware functions, you don't really care much about ports, and in fact configuring ports with many addresses may simply be overhead. Also, as you say, this doesn't address
the external bridging use case where what you're bridging to is not necessarily in Openstack's domain of control.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I know that many NFVs currently prefer to manage everything themselves. At the same time, IMO, I think they should be encouraged
to become Neutronified.</span><span style="color:black"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:black">In “VLAN aware VMs” trunk port mac address has to be globally unique since it can be connected to any network, other ports still only has to be unique per network. But for L2GW all mac addresses has to be globally
unique since they might be bridged together at a later stage. <o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">I'm not sure that that's particularly a problem - any VM with a port will have one globally unique MAC address. I wonder if I'm missing the point here, though.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ok, this was probably too specific, sorry. Neutron can reuse MAC addresses among Neutron networks. But I guess this is configurable.</span><span style="color:black"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:black">Also some implementations might not be able to take VID into account when doing mac address learning, forcing at least unique macs on a trunk network.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">If an implementation struggles with VLANs then the logical thing to do would be not to implement them in that driver. Which is fine: I would expect (for instance) LB-driver networking
to work for this and leave OVS-driver networking to never work for this, because there's little point in fixing it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Same as above, this is related to reuse of MAC addresses.</span><span style="color:black"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:black">Benefits with “VLAN aware VMs” are integration with existing Neutron services.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Benefits with Trunk networks are less consumption of Neutron networks, less management per VLAN.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Actually, the benefit of trunk networks is:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">- if I use an infrastructure where all networks are trunks, I can find out that a network is a trunk<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">- if I use an infrastructure where no networks are trunks, I can find out that a network is not a trunk<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">- if I use an infrastructure where trunk networks are more expensive, my operator can price accordingly<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">And, again, this is all entirely independent of either VLAN-aware ports or L2GW blocks.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Both are true. I was referring of “true” trunk networks, you were referring to your additions, right?</span><span style="color:black"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:black">Benefits with L2GW is ease to do network stitching.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">There are other benefits with the different proposals, the point is that it might be beneficial to have all solutions.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">I totally agree with this.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">So, use cases that come to mind:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">1. I want to pass VLAN-encapped traffic from VM A to VM B. I do not know at network setup time what VLANs I will use.<br>
case A: I'm simulating a network with routers in. The router config is not under my control, so I don't know addresses or the number of VLANs in use. (Yes, this use case exists, search for 'Cisco VIRL'.)<br>
case B: NFV scenarios where the VNF orchestrator decides how few or many VLANs are used, where the endpoints may or may not be addressed, and where the addresses are selected by the VNF manager. (For instance, every time I add a customer to a VNF service I
create another VLAN on an internal link. The orchestrator is intelligent and selects the VLAN; telling Openstack the details is needless overhead.)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> - this use case set suggests VLAN trunks, but says nothing about anything else.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">2. Service VMs, where I'm attaching one VM to many networks so that I can use that VM to implement many instances of the same service. Either the VM won't hotplug VIFs, or it won't hotplug enough VIFs (max # VIFs
<< max # VLANs).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> - this use case set suggests bringing multiple networks into a single port, which is the trunk port use case<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:black"> - addressing would likely be Openstack's responsibility, again suggesting trunk ports<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:black"> - this use case could equally be solved using an L2GW and a trunk network, but that would require more API calls and doesn't add much value<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">3. An external service appliance, where I'm attaching one external port to many networks so that I can use that appliance to implement many instances of the same service.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> - given the external service is probably on a provider network, this suggests that I want to composite multiple tenant networks to a trunked (external) network, indicating an L2GW or an external port specific
extension<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"> - I would probably like the addresses to be under the control of Openstack (so that I can take a tenant network address and prevent it from being re-used, implying that the tenant-side
ports can have addresses<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">4. I want to connect multiple VMs to a trunk network, and some VMs to individual VLANs in the same network<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">(seems useful with my network engineer hat on, but I'm struggling to think of a concrete example)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> - works best with L2GW; also works with two trunk ports<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">5. An anti-use-case: I want to send Neutron's networking into a death spiral by making a forwarding loop<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black"> - the L2GW allows you to do this (connect trunk port to access port); we may want to avoid this 'feature'<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Yes, the loop one also came to my mind.
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Here’s a future use-case: I am an NFV using ports with and without VLANs. Now I want QoS.</span><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">That's still coming out as 'we probably only require one of trunk ports and L2GWs, but both is nicer'. Also, I know that we'd like not to make a mistake here, but we've been talking about this for at least 18
months, so I would prefer that we try for at least one and ideally both of these solutions and risk deprecating them later rather than sitting on the fence for another six months.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Agree.</span><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:black">Platforms that have issues forking of VLANs at VM port level could get around with trunk network + L2GW but having more hacks if integration with other parts of Neutron is needed.
<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">My inclination is that the L2GW should not try and take advantage of the encap in a VLAN-based underlay. It makes it more efficient but ties it too closely with the actual physical implementation of the network.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Not sure I follow, I’ll re read this tomorrow….</span><span style="color:black"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:black">Platforms that have issues implementing trunk networks could get around using “VLAN aware VMs” but being forced to separately manage every VLAN as a Neutron network. On platforms that have both, user can select
method depending on what is needed.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Erik<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="color:black"><br>
-- <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Ian. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">/Erik</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>