https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/SFC-27 sfc <p>This bug was found in both Beryllium master and in stable/lithium.</p> <p>The SF selection algorithms dont appear to be working correctly<br/> when concrete SFs/SFFs are specified in the SFP.</p> <p>Here is an overview of the config</p> <p>SFC:<br/> <span class="error">&#91;TcpProxy, TcpProxy, TcpProxy&#93;</span></p> <p>SFP hops:<br/> SFF2-&gt;SF2<br/> SFF1-&gt;SF1<br/> SFF3-&gt;SF3</p> <p>Im expecting these hops in the RSP:<br/> RSP:<br/> SFF2-&gt;SF2<br/> SFF1-&gt;SF1<br/> SFF3-&gt;SF3</p> <p>With SF selection=RoundRobin, I get this:<br/> RSP:<br/> SFF1-&gt;SF3<br/> SFF2-&gt;SF2<br/> SFF3-&gt;SF1</p> <p>With SF selection=Random, I get this:<br/> RSP:<br/> SFF1-&gt;SF3<br/> SFF2-&gt;SF2<br/> SFF3-&gt;SF3</p> <p>Operating System: All<br/> Platform: All</p> SFC-27

SF selection algorithms are not using SFP concrete details

Bug In Review Unresolved Keith Burns Brady Johnson Wed, 20 May 2015 09:43:43 +0000 Thu, 19 Oct 2017 16:58:58 +0000 unspecified General 0 5 <p>I cannot reproduce the issue in the patch</p> <p>1) patch</p> <p>2) mvn test -Dtest=SfcProviderRenderedPathAPITest | grep TEST</p> <p>13:17:16.977 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4<br/> 13:17:16.978 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4<br/> 13:17:16.985 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF3<br/> 13:17:16.985 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-3<br/> 13:17:16.992 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4<br/> 13:17:16.992 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4<br/> 13:17:16.997 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF5<br/> 13:17:16.997 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-5<br/> 13:17:17.003 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4<br/> 13:17:17.003 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4</p> <p>13:17:21.514 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF2<br/> 13:17:21.514 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-2<br/> 13:17:21.521 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF2<br/> 13:17:21.521 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-2<br/> 13:17:21.528 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF2<br/> 13:17:21.528 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-2<br/> 13:17:21.534 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF1<br/> 13:17:21.534 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-1<br/> 13:17:21.540 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4<br/> 13:17:21.540 <span class="error">&#91;main&#93;</span> INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4</p> <p>Attachment diff has been added with description: test case</p> <p>I also test stable/lithium. The issue cannot be reproduced:</p> <p>topology:<br/> SFF1 &#8211; unittest-fw-1<br/> SFF2 &#8211; unittest-fw-2<br/> SFF3 &#8211; unittest-fw-3<br/> SFF4 &#8211; unittest-fw-4<br/> SFF5 &#8211; unittest-fw-5</p> <p>Use Random schedule, the result:<br/> serviceFunctionForwarderName: SFF4<br/> serviceFunction: unittest-fw-4<br/> serviceFunctionForwarderName: SFF3<br/> serviceFunction: unittest-fw-3<br/> serviceFunctionForwarderName: SFF3<br/> serviceFunction: unittest-fw-3<br/> serviceFunctionForwarderName: SFF5<br/> serviceFunction: unittest-fw-5<br/> serviceFunctionForwarderName: SFF3<br/> serviceFunction: unittest-fw-3</p> <p>I just tested it again on master with the attached JSON configuration, and its still a problem. Looks like your Unit Tests need to be revised as they are not testing the same thing.</p> <p>The RSP is included in the attachment, but here you can see that the SFFs in the hops are ordered <span class="error">&#91;sff3, sff2, sff1&#93;</span> but they should be ordered <span class="error">&#91;sff2, sff1, sff3&#93;</span></p> <p> "rendered-service-paths": {<br/> "rendered-service-path": [<br/> {<br/> "name": "sfc-path1",<br/> "starting-index": 255,<br/> "service-chain-name": "sfc-chain1",<br/> "rendered-service-path-hop": [<br/> </p> { "service-function-forwarder-locator": "ulSff3Ingress", "service-function-forwarder": "sff3", "service-function-name": "sf3", "hop-number": 0, "service-index": 255 } <p>,<br/> </p> { "service-function-forwarder-locator": "ulSff2Ingress", "service-function-forwarder": "sff2", "service-function-name": "sf2", "hop-number": 1, "service-index": 254 } <p>,</p> { "service-function-forwarder-locator": "ulSff1ToSff2", "service-function-forwarder": "sff1", "service-function-name": "sf1", "hop-number": 2, "service-index": 253 } <p> ],<br/> "parent-service-function-path": "sfc-path1",<br/> "path-id": 1,<br/> "transport-type": "service-locator:mac"<br/> },</p> <p>Brady</p> <p>Hi,</p> <p>1. could you pls add test case in attachment?</p> <p>2. could you pls confirm SFF is correctly connected to SF in your test case?</p> <p>SFF1 -&gt; SF1<br/> SFF2 -&gt; SF2<br/> SFF3 -&gt; SF3</p> <p>3. Do you expect rendered service function path is exactly same with service function path?</p> <p>For example, service function path is (SF2, SF1, SF3) so you expect rendered service function path is:</p> <p>hop1: SFF2 -&gt; SF2</p> <p>hop2: SFF1 -&gt; SF1</p> <p>hop3: SFF3 -&gt; SF3</p> <p>4. existing implementation is service function scheduler only check service function chain instead of service function path.</p> <p>Any progress on this? Is this still an issue?</p> <p>Is this still a bug? If so, is it going to be fixed in Lithium-3?</p> <p>Temp marking as Lithium-4 until confirmed it will be in Lithium-3.</p> <p>If the Scheduler is only checking SFC and the SFP is designed to override it (which is has the capability), not only is the scheduler broken (which it is in more ways than one) but then also SFC/SFP validation is horribly broken.</p> <p>This has been resolved I believe... moving to review</p> <p>I don't think this issue was fixed:</p> <p> "service-function-chains": {<br/> "service-function-chain": [<br/> {<br/> "name": "SFC1",<br/> "symmetric": "true",<br/> "sfc-service-function": [<br/> </p> { "name": "dpi-abstract1", "type": "dpi" } <p>,</p> { "name": "firewall-abstract1", "type": "firewall" } <p> ]<br/> }<br/> ]<br/> }</p> <p> "service-function-paths": {<br/> "service-function-path": [<br/> {<br/> "name": "SFP1",<br/> "service-chain-name": "SFC1",<br/> "starting-index": 255,</p> <p> "service-path-hop": [</p> { "hop-number": 0, "service-function-name": "dpi-2", "service-function-forwarder": "SFF2", } <p> ]<br/> }<br/> ]<br/> }</p> <p>dpi-2 is always expected in RSP. but sometimes RSP go through dpi-2 &amp; sometimes RSP go through dpi-1.</p> <p>Moving to Boron.</p> <p>So, does the last comment mean this is no longer "to be verified" in Beryllium, but instead not a blocker and targeted at Boron?</p> <p>This is no longer a Blocking bug for Beryllium as noted by Brady Johnson. I have updated the spreadsheet.</p> <p><a href="https://lists.opendaylight.org/pipermail/sfc-dev/2016-February/002674.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/sfc-dev/2016-February/002674.html</a></p> Development External issue ID 3297 External issue URL ODL SR Target Milestone Priority Rank 0|i02elr: