<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span style="color:#1F497D">Hi Cathy,<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I understand MPLS is a special protocol because:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">- It allows Service Function Path identification (rfc7665) -> compatible with SFC Encapsulation<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">- It doesn’t fully encapsulate the original frames -> incompatible with SFC Encapsulation<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">- Not necessary for this conversation, but also important to keep in mind: it can’t transport additional metadata -> incompatible with SFC Encapsulation<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">So, I will start by discussing NSH specifically (being the fully-compatible SFC Encapsulation protocol). And so, the way I look at insertion modes (if split from correlations) is that in practice they become
 something I would describe as “SFC Proxy modes”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">If a Service Function supports NSH, great, the NSH-encapsulated packets are fully exposed to the SFs and no “SFC Proxy mode” needs to be dictated (NSH is the mechanism itself). So, specifying L2 or L3 for insertion
 types would be of no meaning. At runtime and at the network forwarding level we might witness different ways of reaching the SFs, which could approximate L2 or L3 insertion types – but this isn’t something to be modelled in networking-sfc’s API but rather
 automatically controlled by the backend.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">If a Service Function does not support NSH, we are in the presence of a legacy SF and so more information is needed to model how this SF expects packets (since there is no standard way). Consequently, specifying
 the insertion types, such as L2 or L3, is important. For the former, it means the SF machine has its interfaces running in promiscuous mode and is similar to a switch, for the latter it means the SF machine’s interfaces are not in promiscuous mode and it is
 similar to a router.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">With NSH, these insertion mode details are abstracted from the SFs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The networking backend of neutron/networking-sfc will already know where each VM is and how to reach them and will  be responsible for making sure the NSH packet is delivered to the correct hop without needing
 additional information (from the networking-sfc API).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">So, in summary, L2, L3, NSH and (in practice today @ networking-sfc) MPLS, are all mutually exclusive.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-IE" style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE" style="color:#1F497D">Igor.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><a name="_____replyseparator"></a><b>From:</b> Cathy Zhang [mailto:Cathy.H.Zhang@huawei.com]
<br>
<b>Sent:</b> Monday, March 20, 2017 6:05 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org><br>
<b>Subject:</b> Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi Igor,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Moving the correlation from port-pair to port-pair-group makes sense. In the future I think we should add all new attributes for a SF to port-pair-group-param.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF can support either NSH or MPLS. I would suggest the following:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">port-pair-group (port-pair-group-params):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                insertion-mode:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - L2<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - L3 (default)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">               Correlation: <o:p>
</o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - MPLS<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - NSH<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                tap-enabled:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - False (default)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - True<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Cathy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="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"> Duarte Cardoso, Igor [</span><a href="mailto:igor.duarte.cardoso@intel.com"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">mailto:igor.duarte.cardoso@intel.com</span></a><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">]
<br>
<b>Sent:</b> Monday, March 20, 2017 8:02 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi networking-sfc,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At the latest IRC meeting [1] it was agreed to split TAP from the possible insertion modes (initial spec version [2]).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I took the ARs to propose coexistence of insertion modes, correlation and (now) a new tap-enabled attribute, and send this email about possible directions.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Here are my thoughts, let me know yours:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt">1.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      
</span>My expectation for future PP and PPG if TAP+insertion modes go ahead and nothing else changes (only relevant details outlined):<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">port-pair (service-function-params):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                correlation:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - MPLS<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - None (default)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">port-pair-group (port-pair-group-params):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                insertion-mode:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - L2<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - L3 (default)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                tap-enabled:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - False (default)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - True<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt">2.<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      
</span>What I propose for future PP and PPG (only relevant details outlined):<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">port-pair (service-function-params):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                <remove correlation – reasons outlined in [3] and below><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">port-pair-group (port-pair-group-params):<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                mode:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - L2<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - L3 (default)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - MPLS<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - NSH<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                tap-enabled:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - False (default)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">                                - True<o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-IE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">With what’s proposed in 2.:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">- every combination will be possible with no clashes and no validation required.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">- port-pair-groups will always group “homogeneous” sets of port-pairs, making load-balacing and next-hop processing simpler and consistent.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">- the “forwarding” details of a Service Function are no longer dictated both by port-pair and port-pair-group, but rather only by port-pair-group.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">Are there any use cases for having next-hop SF candidates (individual port-pairs) supporting different SFC Encapsulation protocols?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">I understand, however, that removing correlation from port-pairs might not be ideal given that it’s a subtractive API change.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">[1] </span><a href="http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html"><span lang="EN-IE">http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html</span></a><span lang="EN-IE"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">[2] </span><a href="https://review.openstack.org/#/c/442195/"><span lang="EN-IE">https://review.openstack.org/#/c/442195/</span></a><span lang="EN-IE"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">[3] </span><a href="https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage"><span lang="EN-IE">https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage</span></a><span lang="EN-IE"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-IE">Igor.<o:p></o:p></span></p>
</div>
</body>
</html>