<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=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:MingLiU;
panose-1:2 2 5 9 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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;}
@font-face
{font-family:"\@MingLiU";
panose-1:2 2 5 9 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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">Hi Kevin,<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">Typically we noticed that the underlay switches maintained a table like this:<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">VLAN ID MAC Address Learned-Interface<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">In the physical underlay, with the current architecture if we enable VLAN, the same DVR Unique
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MAC will appear on different VLANs as the packets get DVR Routed.
<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">This will result in the rows of the above tables in the switch to be updated very frequently with new
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">VLANs noted in incoming packets for the same DVR MAC Address, even though they are from the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">same physical port.
<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">We are not sure if all the switches maintained the tables this way , but atleast we
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">saw Openvswitch implementations did. So we consciously did not promote VLANs for
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">initial phase of DVR.<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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<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">Vivek<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 style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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""> Kevin Benton [mailto:blak111@gmail.com]
<br>
<b>Sent:</b> Thursday, September 18, 2014 3:01 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron] DVR Tunnel Design Question<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Can you clarify what you mean with the thrashing condition? MAC addresses only need to be unique per-VLAN so I don't see how the same MAC on multiple VLANs from the same physical port would lead to any issues.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Sep 17, 2014 at 12:41 PM, Armando M. <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">VLAN is on the radar, vxlan/gre was done to start with.<br>
<br>
I believe Vivek mentioned the rationale in some other thread. The gist<br>
of it below:<br>
<br>
In the current architecture, we use a unique DVR MAC per compute node<br>
to forward DVR Routed traffic directly to destination compute node.<br>
The DVR routed traffic from the source compute node will carry<br>
'destination VMs underlay VLAN' in the frame, but the Source Mac in<br>
that same frame will be the DVR Unique MAC. So, same DVR Unique Mac is<br>
used for potentially a number of overlay network VMs that would exist<br>
on that same source compute node.<br>
<br>
The underlay infrastructure switches will see the same DVR Unique MAC<br>
being associated with different VLANs on incoming frames, and so this<br>
would result in VLAN Thrashing on the switches in the physical cloud<br>
infrastructure. Since tunneling protocols carry the entire DVR routed<br>
inner frames as tunnel payloads, there is no thrashing effect on<br>
underlay switches.<br>
<br>
There will still be thrashing effect on endpoints on CNs themselves,<br>
when they try to learn that association between inner frame source MAC<br>
and the TEP port on which the tunneled frame is received. But that we<br>
have addressed in L2 Agent by having a 'DVR Learning Blocker' table,<br>
which ensures that learning for DVR routed packets alone is<br>
side-stepped.<br>
<br>
As a result, VLAN was not promoted as a supported underlay for the<br>
initial DVR architecture.<br>
<br>
Cheers,<br>
Armando<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On 16 September 2014 20:35, <span style="font-family:MingLiU">龚永生</span> <<a href="mailto:gongysh@unitedstack.com">gongysh@unitedstack.com</a>> wrote:<br>
> I think the VLAN should also be supported later. The tunnel should not be<br>
> the prerequisite for the DVR feature.<br>
><br>
><br>
> ------------------ Original ------------------<br>
> From: "Steve Wormley"<<a href="mailto:openstack@wormley.com">openstack@wormley.com</a>>;<br>
> Date: Wed, Sep 17, 2014 10:29 AM<br>
> To: "openstack-dev"<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>;<br>
> Subject: [openstack-dev] [neutron] DVR Tunnel Design Question<br>
><br>
> In our environment using VXLAN/GRE would make it difficult to keep some of<br>
> the features we currently offer our customers. So for a while now I've been<br>
> looking at the DVR code, blueprints and Google drive docs and other than it<br>
> being the way the code was written I can't find anything indicating why a<br>
> Tunnel/Overlay network is required for DVR or what problem it was solving.<br>
><br>
> Basically I'm just trying to see if I missed anything as I look into doing a<br>
> VLAN/OVS implementation.<br>
><br>
> Thanks,<br>
> -Steve Wormley<br>
><br>
><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Kevin Benton<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>