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-141 sfc <p>Hello everyone!</p> <p>I 'm trying to deploy the *<b>SFCOFL2 Tutorial</b>* which is placed in the user-guide of berrylium.</p> <p>I have made it with Lithium odl and I could take the correct flows using these commands on mininet VM:</p> <p>sudo ovs-ofctl -O OpenFlow13 dump-flows s2<br/> sudo ovs-ofctl -O OpenFlow13 dump-flows s3</p> <p>Now, I 'm using the stable/beryllium branch of sfc project.</p> <p>I 'm creating the same topology in the mininet VM:<br/> *<b>sudo mn --topo linear,4 --mac --controller remote,ip=&lt;ip&gt;,port=&lt;port&gt; --switch ovsk,protocols=OpenFlow13</b>*</p> <p>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.</p> <p>The problem is when I create the RSP and the random path-id is bigger than 63!! </p> <p>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:</p> <p>2016-03-22 16:43:06,454 | ERROR | -dispatcher-1907 | SfcL2RspProcessor | 333 - org.opendaylight.sfc.ofl2 - 0.2.1.SNAPSHOT | RuntimeException in processRenderedServicePath: <br/> java.lang.IllegalArgumentException: Invalid range: 174, expected: [<span class="error">&#91;0\u202563&#93;</span>].<br/> at org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev100924.Dscp.check_valueRange(Dscp.java:25)<span class="error">&#91;125:org.opendaylight.mdsal.model.ietf-inet-types:2010.9.24.8_1-SNAPSHOT&#93;</span><br/> at org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev100924.Dscp.&lt;init&gt;(Dscp.java:31)<span class="error">&#91;125:org.opendaylight.mdsal.model.ietf-inet-types:2010.9.24.8_1-SNAPSHOT&#93;</span><br/> at org.opendaylight.sfc.util.openflow.SfcOpenflowUtils.addMatchDscp(SfcOpenflowUtils.java:341)<span class="error">&#91;320:org.opendaylight.sfc.openflow-utils:0.2.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.sfc.l2renderer.openflow.SfcL2FlowProgrammerOFimpl.configurePathMapperSfFlow(SfcL2FlowProgrammerOFimpl.java:686)<span class="error">&#91;333:org.opendaylight.sfc.ofl2:0.2.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.sfc.l2renderer.openflow.SfcL2FlowProgrammerOFimpl.configureVlanPathMapperFlow(SfcL2FlowProgrammerOFimpl.java:669)<span class="error">&#91;333:org.opendaylight.sfc.ofl2:0.2.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.sfc.l2renderer.SfcRspProcessorMpls.configureSfPathMapperFlow(SfcRspProcessorMpls.java:107)<span class="error">&#91;333:org.opendaylight.sfc.ofl2:0.2.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.sfc.l2renderer.SfcL2RspProcessor.configurePathMapperFlows(SfcL2RspProcessor.java:258)<span class="error">&#91;333:org.opendaylight.sfc.ofl2:0.2.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.sfc.l2renderer.SfcL2RspProcessor.processRenderedServicePath(SfcL2RspProcessor.java:105)<span class="error">&#91;333:org.opendaylight.sfc.ofl2:0.2.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.sfc.l2renderer.SfcL2RspDataListener.onDataChanged(SfcL2RspDataListener.java:62)<span class="error">&#91;333:org.opendaylight.sfc.ofl2:0.2.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.md.sal.binding.impl.AbstractForwardedDataBroker$TranslatingDataChangeInvoker.onDataChanged(AbstractForwardedDataBroker.java:143)<span class="error">&#91;173:org.opendaylight.controller.sal-binding-broker-impl:1.3.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.cluster.datastore.DataChangeListener.dataChanged(DataChangeListener.java:66)<span class="error">&#91;198:org.opendaylight.controller.sal-distributed-datastore:1.3.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.cluster.datastore.DataChangeListener.handleReceive(DataChangeListener.java:39)<span class="error">&#91;198:org.opendaylight.controller.sal-distributed-datastore:1.3.1.SNAPSHOT&#93;</span><br/> at org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:34)<span class="error">&#91;194:org.opendaylight.controller.sal-clustering-commons:1.3.1.SNAPSHOT&#93;</span><br/> at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:167)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at akka.actor.Actor$class.aroundReceive(Actor.scala:467)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at akka.actor.ActorCell.invoke(ActorCell.scala:487)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at akka.dispatch.Mailbox.run(Mailbox.scala:220)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)<span class="error">&#91;183:com.typesafe.akka.actor:2.3.14&#93;</span><br/> at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)<span class="error">&#91;180:org.scala-lang.scala-library:2.11.7.v20150622-112736-1fbce4612c&#93;</span><br/> at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)<span class="error">&#91;180:org.scala-lang.scala-library:2.11.7.v20150622-112736-1fbce4612c&#93;</span><br/> at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)<span class="error">&#91;180:org.scala-lang.scala-library:2.11.7.v20150622-112736-1fbce4612c&#93;</span><br/> at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)<span class="error">&#91;180:org.scala-lang.scala-library:2.11.7.v20150622-112736-1fbce4612c&#93;</span></p> <p>Operating System: Linux<br/> Platform: PC</p> SFC-141

Beryllium SFCOFL2 Tutorial - Error in SfcL2RspProcessor (Invalid range)

Bug Resolved Won't Do Javier Arauz Chris Borovas Tue, 22 Mar 2016 15:27:05 +0000 Thu, 19 Oct 2017 16:58:57 +0000 Mon, 6 Jun 2016 13:55:45 +0000 unspecified General 0 3 <p>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.</p> <p><a href="https://github.com/YangModels/yang/blob/master/standard/ietf/RFC/ietf-inet-types@2010-09-24.yang" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/YangModels/yang/blob/master/standard/ietf/RFC/ietf-inet-types@2010-09-24.yang</a> </p> <p> typedef dscp {<br/> type uint8 </p> { range "0..63"; } <p> description<br/> "The dscp type represents a Differentiated Services Code-Point<br/> that may be used for marking packets in a traffic stream.<br/> In the value set and its semantics, this type is equivalent<br/> to the Dscp textual convention of the SMIv2.";<br/> reference<br/> "RFC 3289: Management Information Base for the Differentiated<br/> Services Architecture<br/> RFC 2474: Definition of the Differentiated Services Field<br/> (DS Field) in the IPv4 and IPv6 Headers<br/> RFC 2780: IANA Allocation Guidelines For Values In<br/> the Internet Protocol and Related Headers";<br/> }</p> <p>Hello again! Thank you Suvitha Balu for your notice!</p> <p>That means 2 things:</p> <p>First of all, the Service Function Chains that are created via SFC UI take ids between 0&lt;id&lt;=63 </p> <p>Secondly, we cannot have more than 63 Service Function Chains in our deployment</p> <p>As per the standard yes .<br/> <a href="https://github.com/YangModels/yang/blob/master/standard/ietf/RFC/ietf-inet-types@2010-09-24.yang" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/YangModels/yang/blob/master/standard/ietf/RFC/ietf-inet-types@2010-09-24.yang</a> </p> <p>We can double confirm by checking with SFC project lead Brady Johnson.</p> <p>I have added him in cc list, so lets wait for him comments.</p> <p>@Chris, can you point me to the resource describing the demo you were running? I0ve checked ODL user's guide (<a href="https://www.opendaylight.org/sites/opendaylight/files/bk-user-guide.pdf" class="external-link" target="_blank" rel="nofollow noopener">https://www.opendaylight.org/sites/opendaylight/files/bk-user-guide.pdf</a>) but found no references to a sfcofl2 demo in there...</p> <p>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():</p> <p>444 if (serviceFunctionPath.getPathId() == null) </p> { 445 pathId = SfcServicePathId.check_and_allocate_pathid(); 446 } <p> else </p> { 447 pathId = SfcServicePathId.check_and_allocate_pathid(serviceFunctionPath.getPathId()); 448 } <p>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():</p> <p>687 private FlowBuilder configurePathMapperSfFlow(final long pathId, MatchBuilder match, List&lt;Action&gt; actionList) </p> { 688 SfcOpenflowUtils.addMatchDscp(match, (short) pathId); 689 return configurePathMapperFlow(pathId, match, actionList, FLOW_PRIORITY_PATH_MAPPER+10); 690 } <p>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.</p> <p>As I see it there are two alternatives:</p> <p>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</p> <p>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.</p> <p>I'm asking the project lead his view on which alt. is better.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>(In reply to Brady Johnson from comment #6)<br/> &gt; Regarding a max of 63 Service Chains when using a VLAN Data Plane Locator<br/> &gt; (DPL), your assumptions are correct, since the Service Chain ID is put in<br/> &gt; the 5-bit DSCP field of the IP header.<br/> &gt; <br/> &gt; In addition to the limited number of Service chains that can be created,<br/> &gt; there is no guarantee that the Service Function wont overwrite the DSCP<br/> &gt; field.<br/> &gt; <br/> &gt; This particular demo that uses VLAN is not intended to be used in<br/> &gt; production, but was intended to allow people to easily get started with ODL<br/> &gt; SFC. Having to place the Service Chain ID in the DSCP field highlights the<br/> &gt; need for an improved Service Chaining encapsulation technique, like NSH.<br/> &gt; <br/> &gt; If the above mentioned limitations with VLAN are not acceptable for your<br/> &gt; particular use case, then you will need to switch to using SFC with NSH.</p> <p>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.</p> <p>If no one complains, I'm closing this TR within a few days.</p> <p>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.</p> Development External issue ID 5583 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i02fb3: