Hi,
Finally, I am able to receive VxLAN packets to SFC VM. The issue is that , a
route is missing in the OVS tunnel routing table (ovs-appctl ovs/route/show).
In my compute node, it’s not allowing to add a route until br-int has some IP
in the same subnet. So, I gave an IP address to br-int, which added the route
to OVS tunnel routing table. But, in x86 Compute, If a route is added on
br-int, it’s directly reflecting in OVS tunnel routing table. I need to debug
this issue.
Anyways, Thanks Brady and Sam for your help.
I want some help on SFC Classifier. Currently, I am using the following
classifier:
{"source_port": 2000, "protocol": 6, "dest_port": 80}
The above classifies the TCP traffic which matches the source port as ‘2000’
and destination port as ‘80’ to SFC VM. Now, If I want to classify all the
traffic like TCP/UDP/ICMP …etc with entire port ranges, to SFC VM, what should
be classifier attributes? Is that possible with single classifier?
Regards,
Srikanth.
From: [email protected]
[mailto:[email protected]] On Behalf Of Srikanth Lingala
Sent: Wednesday, February 08, 2017 11:30 PM
To: Sam Hague <[email protected]>; Brady Allen Johnson
<[email protected]>
Cc: [email protected]; [email protected]; Rozet,
Tim <[email protected]>; Ferenc Cserepkei <[email protected]>;
Gorja Gorja <[email protected]>
Subject: Re: [sfc-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH
patches
Hi Sam/Brady,
Somehow, I resolved the table id issue by restarting Opendaylight in Controller
node. Now SFC flows are created across tables 152 -158.
But, still not able to receive VxLAN packets at SFC vNF, when I execute the
curl request from Client to Server.
In the following pastebin location, new flows and br-int bridge details are
described.
http://pastebin.com/CMjK1yrT
Please help me to identify the issue.
Thanks and Regards,
Srikanth.
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Srikanth Lingala
Sent: Wednesday, February 08, 2017 9:34 PM
To: Sam Hague <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
Ferenc Cserepkei
<[email protected]<mailto:[email protected]>>; Gorja
Gorja <[email protected]<mailto:[email protected]>>; Rozet, Tim
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: [sfc-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH
patches
Hi Sam,
I already had the same configuration in the ODL.
root@node-15:~# curl -u admin:admin
http://192.168.0.2:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
{"netvirt-providers-config":{"table-offset":1}}
root@node-15:~# curl -u admin:admin
http://192.168.0.2:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config/
{"sfc-of-renderer-config":{"sfc-of-table-offset":150,"sfc-of-app-egress-table-offset":11}}
Regards,
Srikanth.
From: Sam Hague [mailto:[email protected]]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Srikanth Lingala <[email protected]<mailto:[email protected]>>
Cc: Brady Allen Johnson
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
Gorja Gorja <[email protected]<mailto:[email protected]>>; Rozet, Tim
<[email protected]<mailto:[email protected]>>; Ferenc Cserepkei
<[email protected]<mailto:[email protected]>>;
Veera.Reddy B <[email protected]<mailto:[email protected]>>
Subject: Re: [sfc-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH
patches
On Wed, Feb 8, 2017 at 7:44 AM, Srikanth Lingala
<[email protected]<mailto:[email protected]>> wrote:
Hi Brady,
One more observation is that SFC flows you are talking about, like table 152 –
158 are added in table 2 – 10 in my compute node.
Did you do the step to move the SFC and NetVirt flows to the proper table
offset? Not sure if tacker does that for you, otherwise do it manually: Use
your odl IP in the below commands:
curl -u admin:admin -H 'Content-type: application/json' -X PUT -d
{"netvirt-providers-config":{"table-offset":1}}
http://192.168.0.2:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
curl -u admin:admin -H 'Content-type: application/json' -X PUT -d
'{"sfc-of-renderer-config":{"sfc-of-table-offset":"150","sfc-of-app-egress-table-offset":"11"}}'
http://192.168.0.2:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config
You can check the flows in the below paste link:
http://pastebin.com/MEN7dk8n
It seems some of the flows are missing. I am not able to understand why table
numbers are changed in my compute node. With the same ODL controller, SFC
worked fine with x86 compute node. Then, I attached my aarch64 compute node
with OVS 2.6.1 patches (with DPDK), which is giving issues.
Do I need to do anything different?
Thanks for the help.
Regards,
Srikanth.
From: Sam Hague [mailto:[email protected]<mailto:[email protected]>]
Sent: Tuesday, February 07, 2017 11:22 PM
To: Srikanth Lingala <[email protected]<mailto:[email protected]>>
Cc: Brady Allen Johnson
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
Gorja Gorja <[email protected]<mailto:[email protected]>>; Rozet, Tim
<[email protected]<mailto:[email protected]>>; Ferenc Cserepkei
<[email protected]<mailto:[email protected]>>
Subject: Re: [sfc-dev] [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH
patches
On Tue, Feb 7, 2017 at 12:23 PM, Srikanth Lingala
<[email protected]<mailto:[email protected]>> wrote:
Hi Brady,
One small update.
While creating SFC Classifier, in the karaf logs, I found the following WARNING
messages:
2017-02-06 20:48:47,977 | WARN | NV-SfcDTL-1 |
NetvirtSfcWorkaroundOF13Provider | 295 -
org.opendaylight.netvirt.openstack.net-virt-sfc-impl - 1.3.0.Boron | Failed to
get renderedServicePatch for entry:
Ace{getActions=Actions{augmentations={interface
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.netvirt.sfc.acl.rev150105.RedirectToSfc=RedirectToSfc{getRspName=Path-mychain-Path-114,
isRenderRsp=false}}},
getMatches=Matches{getAceType=AceIp{getDestinationPortRange=DestinationPortRange{getLowerPort=PortNumber
[_value=80], getUpperPort=PortNumber [_value=80], augmentations={}},
getProtocol=6, getSourcePortRange=SourcePortRange{getLowerPort=PortNumber
[_value=2000], getUpperPort=PortNumber [_value=2000], augmentations={}},
augmentations={}}, augmentations={}}, getRuleName=myclass, augmentations={}}
2017-02-06 20:48:53,252 | WARN | NV-SfcDTL-1 |
NetvirtSfcWorkaroundOF13Provider | 295 -
org.opendaylight.netvirt.openstack.net-virt-sfc-impl - 1.3.0.Boron |
handleRenderedServicePath: Could not identify gpe vtep vxgpe -> OF (0) on
Node{getNodeId=Uri
[_value=ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60/bridge/br-int],
getTerminationPoint=[TerminationPoint{getTpId=Uri [_value=br-int],
augmentations={interface
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=35,
getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.InterfaceTypeInternal,
getInterfaceUuid=Uuid [_value=c4d8822d-a58c-4e9a-b02c-4d1a12cd1a9a],
getName=br-int, getOfport=65534, getPortUuid=Uuid
[_value=963afdf4-b908-46d6-b153-32d6b30e5f85]}}}, TerminationPoint{getTpId=Uri
[_value=vxlan-192.168.2.26], augmentations={interface
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=0,
getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.InterfaceTypeVxlan,
getInterfaceUuid=Uuid [_value=fa8eca30-cba1-494c-a039-8019eac50c87],
getName=vxlan-192.168.2.26, getOfport=6,
getOptions=[Options{getOption=local_ip, getValue=192.168.2.1,
augmentations={}}, Options{getOption=remote_ip, getValue=192.168.2.26,
augmentations={}}, Options{getOption=key, getValue=flow, augmentations={}}],
getPortExternalIds=[PortExternalIds{getExternalIdKey=opendaylight-iid,
getExternalIdValue=/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60/bridge/br-int']/network-topology:termination-point[network-topology:tp-id='vxlan-192.168.2.26'],
augmentations={}}], getPortUuid=Uuid
[_value=e91778e6-e44f-49bb-a8da-180a8b5e1a93]}}}, TerminationPoint{getTpId=Uri
[_value=vxlan-192.168.2.2], augmentations={interface
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation{getIfindex=0,
getIngressPolicingBurst=0, getIngressPolicingRate=0, getInterfaceType=class
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.InterfaceTypeVxlan,
getInterfaceUuid=Uuid [_value=4b8ff9cf-8a55-43fa-9a4a-6aeba7e0e0cd],
getName=vxlan-192.168.2.2, getOfport=1, getOptions=[Options{getOption=local_ip,
getValue=192.168.2.1, augmentations={}}, Options{getOption=remote_ip,
getValue=192.168.2.2, augmentations={}}, Options{getOption=key, getValue=flow,
augmentations={}}],
getPortExternalIds=[PortExternalIds{getExternalIdKey=opendaylight-iid,
getExternalIdValue=/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60/bridge/br-int']/network-topology:termination-point[network-topology:tp-id='vxlan-192.168.2.2'],
augmentations={}}], getPortUuid=Uuid
[_value=be986ca9-c1a4-427b-a729-6f5d7675317e]}}}], augmentations={interface
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbBridgeAugmentation=OvsdbBridgeAugmentation{getBridgeExternalIds=[BridgeExternalIds{getBridgeExternalIdKey=opendaylight-iid,
getBridgeExternalIdValue=/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60/bridge/br-int'],
augmentations={}}], getBridgeName=OvsdbBridgeName [_value=br-int],
getBridgeOpenflowNodeRef=KeyedInstanceIdentifier{targetType=interface
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.Node,
path=[org.opendaylight.yang.ge<http://org.opendaylight.yang.ge>n.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.NetworkTopology,
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.Topology[key=TopologyKey
[_topologyId=Uri [_value=ovsdb:1]]],
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.Node[key=NodeKey
[_nodeId=Uri [_value=ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60]]]]},
getBridgeOtherConfigs=[BridgeOtherConfigs{getBridgeOtherConfigKey=hwaddr,
getBridgeOtherConfigValue=ac:ad:fe:4b:69:43, augmentations={}},
BridgeOtherConfigs{getBridgeOtherConfigKey=disable-in-band,
getBridgeOtherConfigValue=true, augmentations={}}], getBridgeUuid=Uuid
[_value=22adf6f1-28d7-4098-a0f7-df732d3e1f9f],
getControllerEntry=[ControllerEntry{getControllerUuid=Uuid
[_value=9eb78a2f-e62f-4ae1-8c6f-21c3ac901d51], getTarget=Uri
[_value=tcp:192.168.0.3:6653<http://192.168.0.3:6653>], isIsConnected=true,
augmentations={}}], getDatapathId=DatapathId [_value=00:00:ac:ad:fe:4b:69:43],
getDatapathType=class
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.DatapathTypeSystem,
getFailMode=class
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbFailModeSecure,
getManagedBy=OvsdbNodeRef [_value=KeyedInstanceIdentifier{targetType=interface
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.Node,
path=[org.opendaylight.yang.ge<http://org.opendaylight.yang.ge>n.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.NetworkTopology,
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.Topology[key=TopologyKey
[_topologyId=Uri [_value=ovsdb:1]]],
org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.Node[key=NodeKey
[_nodeId=Uri [_value=ovsdb://uuid/7e64138d-8a76-4f16-a6d8-35095922bf60]]]]}],
getProtocolEntry=[ProtocolEntry{getProtocol=class
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbBridgeProtocolOpenflow13,
augmentations={}}]}}}
One thing I am not able to understand is that ODL is trying to get RSP
‘Path-mychain-Path-114’, which is not there. When I check the RSP in the DLUX
SFC UI, I saw the RSP as ‘Path-mychain-Path-140’. Am I missing anything here?
This and the logs above match what Brady suspected - the chain isn't being
built or the wrong one being requested. in the workflow you build the chain,
then add the classifier. Those are the awarnings you see form netvirt - it
can't get the RSP. The other warning is not finding the vxgpe port, which also
added during the chain creation.
Seems like I recall a bug at some point where the wrong chain name was used.
Can't remember if that was from the tacker side or something else. Maybe Brady
can remember.
Regards,
Srikanth.
From: Srikanth Lingala
Sent: Tuesday, February 07, 2017 9:50 PM
To: 'Brady Allen Johnson'
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: Ferenc Cserepkei
<[email protected]<mailto:[email protected]>>; Manuel
Buil <[email protected]<mailto:[email protected]>>; Rozet, Tim
<[email protected]<mailto:[email protected]>>; Veera.Reddy B
<[email protected]<mailto:[email protected]>>; Gorja Gorja
<[email protected]<mailto:[email protected]>>
Subject: RE: [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH patches
Hi Brady,
While adding SFC and SFC Classifier, I can’t see any valid errors in karaf.log.
Anyways, I am pasting WARN and ERROR logs of sfc in the below link:
Karaf warning messages:
http://pastebin.com/PCa4QFft
Karaf error messages:
http://pastebin.com/34CmBjZW
But, some of the karaf logs are old ones also.
And also, I observer below errors at Openvswitch log
(/var/log/openvswitch/ovs-vswitchd2.log):
2017-02-06T18:34:59.555Z|00110|netdev_vport|WARN|vxgpe: unknown vxlan argument
'nsp'
2017-02-06T18:34:59.555Z|00111|netdev_vport|WARN|vxgpe: unknown vxlan argument
'nshc2'
2017-02-06T18:34:59.555Z|00112|netdev_vport|WARN|vxgpe: unknown vxlan argument
'nshc3'
2017-02-06T18:34:59.555Z|00113|netdev_vport|WARN|vxgpe: unknown vxlan argument
'nshc4'
2017-02-06T18:34:59.556Z|00114|netdev_vport|WARN|vxgpe: unknown vxlan argument
'nsi'
2017-02-06T18:34:59.556Z|00115|netdev_vport|WARN|vxgpe: unknown vxlan argument
'nshc1'
2017-02-06T18:34:59.556Z|00116|netdev_linux|WARN|br-int: removing policing
failed: Operation not supported
2017-02-06T18:34:59.556Z|00117|netdev_linux|WARN|br-phy1: removing policing
failed: Operation not supported
2017-02-06T18:36:15.772Z|00001|ofproto_dpif_xlate(pmd9)|ERR|over max
translation depth 64:
tcp,in_port=4,vlan_tci=0x0000,dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123.123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2000,tp_dst=80,tcp_flags=syn
2017-02-06T18:36:17.029Z|00001|ofproto_dpif_xlate(revalidator10)|ERR|over max
translation depth 64:
tcp,in_port=4,vlan_tci=0x0000,dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123.123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2000,tp_dst=80,tcp_flags=syn
2017-02-06T18:36:46.820Z|00002|ofproto_dpif_xlate(pmd9)|ERR|over max
translation depth 64:
tcp,in_port=4,vlan_tci=0x0000,dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123.123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2000,tp_dst=80,tcp_flags=syn
2017-02-06T18:37:18.884Z|00003|ofproto_dpif_xlate(pmd9)|ERR|over max
translation depth 64:
tcp,in_port=4,vlan_tci=0x0000,dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123.123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2000,tp_dst=80,tcp_flags=syn
2017-02-06T18:37:19.580Z|00002|ofproto_dpif_xlate(revalidator10)|ERR|over max
translation depth 64:
tcp,in_port=4,vlan_tci=0x0000,dl_src=fa:16:3e:f1:08:d3,dl_dst=fa:16:3e:03:7c:6a,nw_src=123.123.123.5,nw_dst=123.123.123.4,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2000,tp_dst=80,tcp_flags=syn
Does the above error messages are anything to do with the adding of SFC flows
in the compute node?
Regards,
Srikanth.
From: Brady Allen Johnson [mailto:[email protected]]
Sent: Tuesday, February 07, 2017 3:55 PM
To: Srikanth Lingala
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: Ferenc Cserepkei
<[email protected]<mailto:[email protected]>>; Manuel
Buil <[email protected]<mailto:[email protected]>>; Rozet, Tim
<[email protected]<mailto:[email protected]>>; Veera.Reddy B
<[email protected]<mailto:[email protected]>>; Gorja Gorja
<[email protected]<mailto:[email protected]>>
Subject: [SFC] ODL SFC with single compute node and OVS 2.6.1 NSH patches
Srikanth,
The reason wget works and doesnt send packets to the VM is because your
classification rule (pasted below) matches on srcPort=2000 and dstPort=80, but
you dont specify the srcPort with wget, so the packets dont match
classification, and subsequently dont get sent to SFC (hence they dont go the
VNF VM). The packets go directly from the client to the server.
This is your classification flow:
cookie=0x1110010000510255, duration=1268.611s, table=11, n_packets=896,
n_bytes=66304, tcp,reg0=0x1,tp_src=2000,tp_dst=80
actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_NSH_C2[],push_nsh,load:0x1->NXM_NX_NSH_MDTYPE[],load:0x3->NXM_NX_NSH_NP[],load:0xc0a8001a->NXM_NX_NSH_C1[],load:0x33->NXM_NX_NSP[0..23],
load:0xff->NXM_NX_NSI[],load:0x7b7b7b03->NXM_NX_TUN_IPV4_DST[],load:0x33->NXM_NX_TUN_ID[0..31],resubmit(,0)
Looking at the flows in more detail, I dont see the SFC flows, which is why the
packets dont go to the VNF VM when you use curl. When SFC is used with Netvirt
for OPNFV (which is what you're doing here) the SFC flows should be in tables 0
and tables 152-158. The largest table I see here is 111. Netvirt is working
correctly, and sending the packets to SFC, but the SFC flows dont exist.
Can you check the ODL logs to see if something failed in SFC. The ODL logs are
usually in /opt/opendaylight/data/logs/karaf.log* Just do this grep to see what
happened:
grep -i sfc /opt/opendaylight/data/logs/karaf.log*
Regards,
Brady
On 07/02/17 09:24, Srikanth Lingala wrote:
Hi,
My setup includes:
• One Openstack Controller with ODL (of course with SFC) which is
deployed through OPNFV Colorado 3.0
• One aarch64 Compute Node (OpenStack Mitaka), which is attached to the
above OS Controller
I downloaded OVS 2.6.1 from OVS git hub and applied NSH patches from below URL:
https://github.com/yyang13/ovs_nsh_patches/tree/master/v2.6.1
I am able to create the SFC attributes like VNFD, VNF, Chain, and Classifier
through Tim Rozet SFC walkthrough
(https://github.com/trozet/sfc-random/blob/master/tacker_sfc_apex_walkthrough.txt).
And also, I launched VNF, http_server and http_client VM’s on the same compute
node.
All the related NSH flows are added to the bridge ‘br-int’ in the compute node
without fail.
But, when I execute the command ‘curl --local-port 2000 123.123.123.4’ from the
http_client VM, I am getting the below error message:
curl: (7) Failed to connect to 123.123.123.4 port 80: Connection timed out
When I execute the command ‘wget 123.123.123.4’ from the http_client VM, I am
getting the 200 OK response.
But, in both the cases, no VxLAN packets are coming at the tacker VNF VM (using
vxlan_tool.py).
OVS bridges and flows details of Compute Node are given at the below link:
http://pastebin.com/MEN7dk8n
Can anyone give me some clue, to debug the issue.
I also want to know, whether anyone one are succeeded while executing SFC
across compute node through ODL and OVS 2.6.1 with NSH patches from Yang.
Thanks for the help.
Regards,
Srikanth.
_______________________________________________
sfc-dev mailing list
[email protected]<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
