<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi Igor,<br><br></div> <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 10:02 PM, Duarte Cardoso, Igor <span dir="ltr"><<a href="mailto:igor.duarte.cardoso@intel.com" target="_blank">igor.duarte.cardoso@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-5810197258979053678WordSection1">
<p class="MsoNormal"><a name="m_-5810197258979053678__MailEndCompose"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">Hi Vikash,<u></u><u></u></span></a></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">It’s best to start with RFC 7665.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">NSH decouples traffic forwarding from both the internals of packets and service functions. A special entity called SFF will take on that job. L2/L3 then become
something that the SFF might have to deal with it. </span></p></div></div></blockquote><div><br><div style="font-family:verdana,sans-serif;display:inline" class="gmail_default">which means it can co-exist with (L2/L3 insertion mode) and not necessarily mutually exclusive.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-5810197258979053678WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">However, networking-sfc API doesn’t expose or require details about individual SFC dataplane elements such as the SFF… it is up to the backend/driver to know those low-level details.</span></p></div></div></blockquote><div><br><div style="font-family:verdana,sans-serif;display:inline" class="gmail_default">Agree.<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-5810197258979053678WordSection1"><p class="MsoNormal"> </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-5810197258979053678WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">NSH doesn’t classify and forward traffic itself. It’s only a header that identifies what and where in the chain the packet belongs to/is (plus other goodies such
as metadata). Classifier will classify, SFF will forward.</span></p></div></div></blockquote><div><br><div style="font-family:verdana,sans-serif;display:inline" class="gmail_default"> I was referring to NSH
in totality and not excluding SFF
(<a href="https://tools.ietf.org/html/draft-ietf-sfc-nsh-12">https://tools.ietf.org/html/draft-ietf-sfc-nsh-12</a>). Look like I extended the scope of NSH in term of SFC. </div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-5810197258979053678WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">By the way, I left a question on the tap blueprint whiteboard, I’ll copy it here too:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">“Is there a use case for "tap chains"? I.e. not only you send traffic to your tap function, but then your tap function also sends traffic to a next hop too, so
a full chain starts after traffic gets tapped at the first chain (the first chain also continues).”<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)">I suppose the answer is no since you mentioned “Note - TAP SFs do not forward packet”, but I’m happy to hear extended info about this – from anyone reading.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-IE">Best regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)" lang="EN-IE">Igor.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><a name="m_-5810197258979053678______replyseparator"></a><b><span style="font-size:11pt;font-family:"calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"calibri",sans-serif"> Vikash Kumar [mailto:<a href="mailto:vikash.kumar@oneconvergence.com" target="_blank">vikash.kumar@<wbr>oneconvergence.com</a>]
<br>
<b>Sent:</b> Tuesday, March 21, 2017 3:32 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<wbr>openstack.org</a>><br>
<b>Subject:</b> Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation<u></u><u></u></span></p><div><div class="gmail-h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-family:"verdana",sans-serif">Hi,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-family:"verdana",sans-serif"> Moving definition of SF from port-pair to port-pair-group looks good.
<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-family:"verdana",sans-serif"> TAP is also an insertion mode like L2/L3 but since it simplifies to keep 'tap-enabled' field also in port-pair-group, so it should be fine from implementation
point of view (Note - TAP SFs do not forward packet). TAP enabled and L2/L3 insertion mode should be mutually exclusive.
<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"verdana",sans-serif"> According to IETF draft NSH can classify & forward traffic (correct ?) but then the draft assumes uniformity of working of devices (which IMHO refers L3) which doesn't cover the entire use
case. Can insertion mode (L2/L3) & traffic encapsulation(NSH) co-exist also ? <u></u>
<u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"verdana",sans-serif"><br>
<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com" target="_blank">Cathy.H.Zhang@huawei.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Hi Igor,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
port-pair-group (port-pair-group-params):<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
insertion-mode:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - L2<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - L3 (default)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
Correlation: <u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - MPLS<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - NSH<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
tap-enabled:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - False (default)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - True<u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Thanks,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Cathy</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:"tahoma",sans-serif">From:</span></b><span style="font-size:10pt;font-family:"tahoma",sans-serif"> Duarte Cardoso, Igor [mailto:<a href="mailto:igor.duarte.cardoso@intel.com" target="_blank">igor.duarte.cardoso@<wbr>intel.com</a>]
<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</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Hi networking-sfc,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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]).<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Here are my thoughts, let me know yours:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="gmail-m_-5810197258979053678m8735276103575523103m-4542994552255199751msolistparagraph">1.<span style="font-size:7pt">
</span>My expectation for future PP and PPG if TAP+insertion modes go ahead and nothing else changes (only relevant details outlined):<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
port-pair (service-function-params):<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
correlation:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - MPLS<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - None (default)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
port-pair-group (port-pair-group-params):<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
insertion-mode:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - L2<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - L3 (default)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
tap-enabled:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - False (default)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - True<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="gmail-m_-5810197258979053678m8735276103575523103m-4542994552255199751msolistparagraph">2.<span style="font-size:7pt">
</span>What I propose for future PP and PPG (only relevant details outlined):<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
port-pair (service-function-params):<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<remove correlation – reasons outlined in [3] and below><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
port-pair-group (port-pair-group-params):<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
mode:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - L2<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - L3 (default)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - MPLS<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - NSH<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
tap-enabled:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - False (default)<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36pt">
<wbr> - True<u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE">With what’s proposed in 2.:</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE">- every combination will be possible with no clashes and no validation required.</span><u></u><u></u></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.</span><u></u><u></u></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.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE"> </span><u></u><u></u></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?</span><u></u><u></u></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.</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE">[1]
<a href="http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html" target="_blank">
http://eavesdrop.openstack.<wbr>org/meetings/service_chaining/<wbr>2017/service_chaining.2017-03-<wbr>16-17.02.html</a></span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE">[2]
<a href="https://review.openstack.org/#/c/442195/" target="_blank">https://review.openstack.org/#<wbr>/c/442195/</a></span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE">[3]
<a href="https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage" target="_blank">
https://github.com/openstack/<wbr>networking-sfc/blob/<wbr>17c537b35d41a3e1fd80da790ae668<wbr>e52cea6b88/doc/source/system_<wbr>design%20and_workflow.rst#<wbr>usage</a></span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE"> </span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE">Best regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span lang="EN-IE">Igor.</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"trebuchet ms",sans-serif">Regards,</span><u></u><u></u></p>
</div>
<p class="MsoNormal"><span style="font-family:"trebuchet ms",sans-serif">Vikash</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-family:trebuchet ms,sans-serif">Regards,<br></span></div><span style="font-family:trebuchet ms,sans-serif">Vikash</span><br></div></div>
</div></div>