[SFC-141] Beryllium SFCOFL2 Tutorial - Error in SfcL2RspProcessor (Invalid range) Created: 22/Mar/16 Updated: 19/Oct/17 Resolved: 06/Jun/16 |
|
| Status: | Resolved |
| Project: | sfc |
| Component/s: | General |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Chris Borovas | Assignee: | Javier Arauz |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: Linux |
||
| External issue ID: | 5583 |
| Priority: | Normal |
| Description |
|
Hello everyone! I 'm trying to deploy the *SFCOFL2 Tutorial* which is placed in the user-guide of berrylium. I have made it with Lithium odl and I could take the correct flows using these commands on mininet VM: sudo ovs-ofctl -O OpenFlow13 dump-flows s2 Now, I 'm using the stable/beryllium branch of sfc project. I 'm creating the same topology in the mininet VM: I have fixed my json data to create correctly the SFFs with their related SFs DPL and I 'm seeing them to the SFC UI. The problem is when I create the RSP and the random path-id is bigger than 63!! If randomly the path-id is for example 40 the flows are created succesfuly in the s2 and s3 bridges, but if the path-id is 174 or something bigger than 63 the following exception is appeared: 2016-03-22 16:43:06,454 | ERROR | -dispatcher-1907 | SfcL2RspProcessor | 333 - org.opendaylight.sfc.ofl2 - 0.2.1.SNAPSHOT | RuntimeException in processRenderedServicePath: |
| Comments |
| Comment by Suvitha Balu [ 26/May/16 ] |
|
The Exception expected when we pass the value more than 63. Please fine the below link for ietf.inet.types std for DSCP value range. https://github.com/YangModels/yang/blob/master/standard/ietf/RFC/ietf-inet-types@2010-09-24.yang typedef dscp { description |
| Comment by Chris Borovas [ 26/May/16 ] |
|
Hello again! Thank you Suvitha Balu for your notice! That means 2 things: First of all, the Service Function Chains that are created via SFC UI take ids between 0<id<=63 Secondly, we cannot have more than 63 Service Function Chains in our deployment |
| Comment by Suvitha Balu [ 26/May/16 ] |
|
As per the standard yes . We can double confirm by checking with SFC project lead Brady Johnson. I have added him in cc list, so lets wait for him comments. |
| Comment by Javier Arauz [ 27/May/16 ] |
|
@Chris, can you point me to the resource describing the demo you were running? I0ve checked ODL user's guide (https://www.opendaylight.org/sites/opendaylight/files/bk-user-guide.pdf) but found no references to a sfcofl2 demo in there... |
| Comment by Javier Arauz [ 30/May/16 ] |
|
The RSP path-id value is randomly generated if not provided in the SFP the RSP is generated from, check org.opendaylight.sfc.provider.api.SfcProviderRenderedPathAPI.createRenderedServicePathEntry(): 444 if (serviceFunctionPath.getPathId() == null) { 445 pathId = SfcServicePathId.check_and_allocate_pathid(); 446 }else { 447 pathId = SfcServicePathId.check_and_allocate_pathid(serviceFunctionPath.getPathId()); 448 }Later, when programming the OF switches using VLAN DPLs, the path-id is squeezed into the (shorter) DSCP field match of OF rules, check org.opendaylight.sfc.l2renderer.openflow.SfcL2FlowProgrammerOFimpl.configurePathMapperSfFlow(): 687 private FlowBuilder configurePathMapperSfFlow(final long pathId, MatchBuilder match, List<Action> actionList) { 688 SfcOpenflowUtils.addMatchDscp(match, (short) pathId); 689 return configurePathMapperFlow(pathId, match, actionList, FLOW_PRIORITY_PATH_MAPPER+10); 690 }Line 688 in the later snippet shall raise an exception if the value generated in line 445 from the former snippet is greater than 63. As I see it there are two alternatives: 1) When using VLAN DPLs in a SFP, make sure a path ID lower than 64 is provided when provisioning such SFP. Then line 447 from the former snippet will be run and the provisioned path ID shall be assigned to the RSP. This may be cumbersome, so 2) before squeezing the path ID into the DSCP field, cut it down to 6 bits. Doing this should cause no harm since the ingress classifier shall cut the path ID down to 6 bits when squeezing it into the IP header of packets belonging to this RSP. I'm asking the project lead his view on which alt. is better. |
| Comment by Brady Johnson [ 30/May/16 ] |
|
Regarding a max of 63 Service Chains when using a VLAN Data Plane Locator (DPL), your assumptions are correct, since the Service Chain ID is put in the 5-bit DSCP field of the IP header. In addition to the limited number of Service chains that can be created, there is no guarantee that the Service Function wont overwrite the DSCP field. This particular demo that uses VLAN is not intended to be used in production, but was intended to allow people to easily get started with ODL SFC. Having to place the Service Chain ID in the DSCP field highlights the need for an improved Service Chaining encapsulation technique, like NSH. If the above mentioned limitations with VLAN are not acceptable for your particular use case, then you will need to switch to using SFC with NSH. |
| Comment by Javier Arauz [ 31/May/16 ] |
|
(In reply to Brady Johnson from comment #6) I'm assuming then alternative 1 is the preferred one. @Chris, please update your JSON restconf files so a path id lower than 64 is included in SFP definitions. If no one complains, I'm closing this TR within a few days. |
| Comment by Javier Arauz [ 06/Jun/16 ] |
|
SFC using VLAN was a temporary solution until NSH were in place. Since this issue can be solved by means of manual configuration of SFPs, no fixes will be performed in the code. |