<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:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"\@SimSun";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
/* 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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        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";}
span.EmailStyle19
        {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 Russell,<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">Please see inline.<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">Cathy<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""> Russell Bryant [mailto:russell@ovn.org]
<br>
<b>Sent:</b> Tuesday, July 19, 2016 6:51 AM<br>
<b>To:</b> Cathy Zhang<br>
<b>Cc:</b> Farhad Sunavala; dev@openvswitch.org; Russell Bryant; Kyle Mestery<br>
<b>Subject:</b> Re: [ovs-dev] SFC-Summary: MultiTenant<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Even putting the multi-tenant considerations aside, I think sub-ports (tagging or encapsulation) are valuable as a mechanism to differentiate between different chains (traffic matched with different classifiers). <span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Cathy> Definitely. Using virtual sub-ports to differentiate different chains will greatly improve the OVS performance since this eliminates the need for re-classification
 at each hop. It also solves the problem caused by “some SF/VNF could change the 5-tuple or n-tuple fields of the packets that are used for chain flow classification”.  Based on info from John of Palo Alto networks, their VNF is alreadt using different virtual
 ports to differentiate different chains. <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">I agree that it's also complex that it requires coordination with the VNF - both with the vendors and a mechanism to coordinate with VNFs at runtime.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Cathy> The correlation between the sub-port and the chain needs to be communicated to the OVS as well as to the VNF. Networking-sfc’s chain API already has
 this info and passes this info down to the driver and OVS. The same information can be passed to VNF Manager which in turn passes to VNF. But as you said, we need coordination with the VNF manager. Different vendors could have different VNF managers. We need
 some agreement there. <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>
<p class="MsoNormal">I'd really like to understand better what people building VNFs are doing and what they want.  So many SFC conversations feel like vendors trying to guess.  I haven't actually talked to any users myself.  I just want to build what people
 will actually use.  :-)<o:p></o:p></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">Cathy> There are many different types of VNFs. Some VNFs could have a need for passing of some metadata to the next hop VNF. I would also like to hear more
 use cases</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Jul 13, 2016 at 6:18 PM, Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com" target="_blank">Cathy.H.Zhang@huawei.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi Russell,<br>
<br>
To add on Farhad's point, with current neutron and nova, we cannot create a multi-tenant  VNF.<br>
Currently, nova checks whether the neutron port belongs to the same tenant as the VM itself.<br>
You attach a network interface (neutron port) to a VM using nova interface-attach, if the port and the VM are in different tenants, an error is given.<br>
<br>
As to the sub-ports feature of Neutron, although it allows the sub-ports to associate with different networks, it seems these networks need to all belong to the same tenant according to vlan-aware-vms spec
<a href="http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html" target="_blank">
http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html</a>.<br>
<br>
It is not clear whether it can work properly if these networks belong to different tenants.<br>
DO you know this? We may need to send an email to Neutron team for clarification on this.<br>
<br>
Thanks,<br>
Cathy<br>
<br>
-----Original Message-----<br>
From: dev [mailto:<a href="mailto:dev-bounces@openvswitch.org">dev-bounces@openvswitch.org</a>] On Behalf Of Farhad Sunavala<br>
Sent: Tuesday, July 12, 2016 7:59 PM<br>
To: <a href="mailto:dev@openvswitch.org">dev@openvswitch.org</a><br>
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant<br>
<br>
>I was thinking this could be handled with child / sub-ports.  We do<br>
>this today for containers in VMs.  We can have a single VIF for a VM<br>
>that is connected to multiple networks that are owned by separate<br>
>tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)<br>
>would be used to differentiate the traffic for each networking in/out<br>
>of that VIF.  I had started adding the ability to use MPLS for this in<br>
>my prototype for this reason, as that was what networking-sfc had defined.<br>
I have a quick question on the above. (multi-tenancy).Yes, I know the containers can be in different networks of the same tenant.How does it work when the containers are in different tenants ?<br>
Below is the latest spec for vlan-aware-vms <a href="https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html" target="_blank">
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html</a><br>
<br>
The trick is to create neutron ports (for the subports) and then link them to the trunk port using neutron trunk-subport-add TRUNK \   PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]<br>
<br>
In the above command all the neutron ports (trunk  ports and subports) must be in the same tenant.As far as I know, a tenant will not see neutron ports from another tenant.    Or will this command allow neutron ports from different tenants to be attached ?<br>
E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C10000 (network dn1)container C2 in Tenant 2 with portID = C20000 (network dn2)The trunk port of VM "X" is in tenant 100 with portID = T10000 (network dt) The above command will be neutron trunk-subport-add
 T10000 \   A  vlan 10000 \   B vlan 20000 Is my understanding correct? thanks,Farhad.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openvswitch.org">dev@openvswitch.org</a><br>
<a href="http://openvswitch.org/mailman/listinfo/dev" target="_blank">http://openvswitch.org/mailman/listinfo/dev</a><br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openvswitch.org">dev@openvswitch.org</a><br>
<a href="http://openvswitch.org/mailman/listinfo/dev" target="_blank">http://openvswitch.org/mailman/listinfo/dev</a><o:p></o:p></p>
</div>
</div>
</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>
<div>
<div>
<p class="MsoNormal">Russell Bryant<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>