[SFC-27] SF selection algorithms are not using SFP concrete details Created: 20/May/15  Updated: 19/Oct/17

Status: In Review
Project: sfc
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Brady Johnson Assignee: Keith Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: HTML File diff    
External issue ID: 3297
Priority: Normal

 Description   

This bug was found in both Beryllium master and in stable/lithium.

The SF selection algorithms dont appear to be working correctly
when concrete SFs/SFFs are specified in the SFP.

Here is an overview of the config

SFC:
[TcpProxy, TcpProxy, TcpProxy]

SFP hops:
SFF2->SF2
SFF1->SF1
SFF3->SF3

Im expecting these hops in the RSP:
RSP:
SFF2->SF2
SFF1->SF1
SFF3->SF3

With SF selection=RoundRobin, I get this:
RSP:
SFF1->SF3
SFF2->SF2
SFF3->SF1

With SF selection=Random, I get this:
RSP:
SFF1->SF3
SFF2->SF2
SFF3->SF3

 Comments   
Comment by Ruijing Guo [ 03/Jun/15 ]

I cannot reproduce the issue in the patch

1) patch

2) mvn test -Dtest=SfcProviderRenderedPathAPITest | grep TEST

13:17:16.977 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4
13:17:16.978 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4
13:17:16.985 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF3
13:17:16.985 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-3
13:17:16.992 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4
13:17:16.992 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4
13:17:16.997 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF5
13:17:16.997 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-5
13:17:17.003 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4
13:17:17.003 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4

13:17:21.514 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF2
13:17:21.514 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-2
13:17:21.521 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF2
13:17:21.521 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-2
13:17:21.528 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF2
13:17:21.528 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-2
13:17:21.534 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF1
13:17:21.534 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-1
13:17:21.540 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunctionForwarderName: SFF4
13:17:21.540 [main] INFO o.o.s.p.a.SfcProviderRenderedPathAPI - TEST serviceFunction: unittest-fw-4

Comment by Ruijing Guo [ 03/Jun/15 ]

Attachment diff has been added with description: test case

Comment by Ruijing Guo [ 04/Jun/15 ]

I also test stable/lithium. The issue cannot be reproduced:

topology:
SFF1 – unittest-fw-1
SFF2 – unittest-fw-2
SFF3 – unittest-fw-3
SFF4 – unittest-fw-4
SFF5 – unittest-fw-5

Use Random schedule, the result:
serviceFunctionForwarderName: SFF4
serviceFunction: unittest-fw-4
serviceFunctionForwarderName: SFF3
serviceFunction: unittest-fw-3
serviceFunctionForwarderName: SFF3
serviceFunction: unittest-fw-3
serviceFunctionForwarderName: SFF5
serviceFunction: unittest-fw-5
serviceFunctionForwarderName: SFF3
serviceFunction: unittest-fw-3

Comment by Brady Johnson [ 05/Jun/15 ]

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.

The RSP is included in the attachment, but here you can see that the SFFs in the hops are ordered [sff3, sff2, sff1] but they should be ordered [sff2, sff1, sff3]

"rendered-service-paths": {
"rendered-service-path": [
{
"name": "sfc-path1",
"starting-index": 255,
"service-chain-name": "sfc-chain1",
"rendered-service-path-hop": [

{ "service-function-forwarder-locator": "ulSff3Ingress", "service-function-forwarder": "sff3", "service-function-name": "sf3", "hop-number": 0, "service-index": 255 }

,

{ "service-function-forwarder-locator": "ulSff2Ingress", "service-function-forwarder": "sff2", "service-function-name": "sf2", "hop-number": 1, "service-index": 254 }

,

{ "service-function-forwarder-locator": "ulSff1ToSff2", "service-function-forwarder": "sff1", "service-function-name": "sf1", "hop-number": 2, "service-index": 253 }

],
"parent-service-function-path": "sfc-path1",
"path-id": 1,
"transport-type": "service-locator:mac"
},

Brady

Comment by Ruijing Guo [ 08/Jun/15 ]

Hi,

1. could you pls add test case in attachment?

2. could you pls confirm SFF is correctly connected to SF in your test case?

SFF1 -> SF1
SFF2 -> SF2
SFF3 -> SF3

3. Do you expect rendered service function path is exactly same with service function path?

For example, service function path is (SF2, SF1, SF3) so you expect rendered service function path is:

hop1: SFF2 -> SF2

hop2: SFF1 -> SF1

hop3: SFF3 -> SF3

4. existing implementation is service function scheduler only check service function chain instead of service function path.

Comment by Reinaldo Penno [ 09/Sep/15 ]

Any progress on this? Is this still an issue?

Comment by Keith Burns [ 12/Oct/15 ]

Is this still a bug? If so, is it going to be fixed in Lithium-3?

Temp marking as Lithium-4 until confirmed it will be in Lithium-3.

Comment by Keith Burns [ 14/Oct/15 ]

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.

Comment by Keith Burns [ 07/Jan/16 ]

This has been resolved I believe... moving to review

Comment by Ruijing Guo [ 25/Jan/16 ]

I don't think this issue was fixed:

"service-function-chains": {
"service-function-chain": [
{
"name": "SFC1",
"symmetric": "true",
"sfc-service-function": [

{ "name": "dpi-abstract1", "type": "dpi" }

,

{ "name": "firewall-abstract1", "type": "firewall" }

]
}
]
}

"service-function-paths": {
"service-function-path": [
{
"name": "SFP1",
"service-chain-name": "SFC1",
"starting-index": 255,

"service-path-hop": [

{ "hop-number": 0, "service-function-name": "dpi-2", "service-function-forwarder": "SFF2", }

]
}
]
}

dpi-2 is always expected in RSP. but sometimes RSP go through dpi-2 & sometimes RSP go through dpi-1.

Comment by Brady Johnson [ 11/Feb/16 ]

Moving to Boron.

Comment by Colin Dixon [ 11/Feb/16 ]

So, does the last comment mean this is no longer "to be verified" in Beryllium, but instead not a blocker and targeted at Boron?

Comment by A H [ 11/Feb/16 ]

This is no longer a Blocking bug for Beryllium as noted by Brady Johnson. I have updated the spreadsheet.

https://lists.opendaylight.org/pipermail/sfc-dev/2016-February/002674.html

Generated at Wed Feb 07 20:38:26 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.