Re: [openflowplugin-dev] [L2switch-dev] Flow ID in operational

Yes - Shuva. That's what I meant by the same format - same format for the new design as was the case for older design. On Friday, April 15, 2016, Shuva Jyoti Kar wrote: > I think it would be better to use the [#UF$TABLE*0-7] for flow id in case > of flows that are

Re: [openflowplugin-dev] [L2switch-dev] Flow ID in operational

I think it would be better to use the [#UF$TABLE*0-7] for flow id in case of flows that are installed through RPC to prevent any nasty bugs. Date: Fri, 15 Apr 2016 15:31:15 -0700 From: Abhijit Kumbhare > To: Anil Vishnoi

Re: [openflowplugin-dev] [L2switch-dev] Flow ID in operational

Yes. On Fri, Apr 15, 2016 at 3:29 PM, Anil Vishnoi wrote: > By same mechanism you mean, using the same format for the flow-id creation? > > On Fri, Apr 15, 2016 at 3:27 PM, Abhijit Kumbhare > wrote: > >> In-line. >> >> On Fri, Apr 15, 2016 at 2:27

Re: [openflowplugin-dev] [L2switch-dev] Flow ID in operational

By same mechanism you mean, using the same format for the flow-id creation? On Fri, Apr 15, 2016 at 3:27 PM, Abhijit Kumbhare wrote: > In-line. > > On Fri, Apr 15, 2016 at 2:27 PM, Anil Vishnoi > wrote: > >> Abhijit, for RPC,s flow id doesn't

Re: [openflowplugin-dev] [L2switch-dev] Flow ID in operational

Abhijit, for RPC,s flow id doesn't matter, because they just ignore it, because OF switch don't have any flow id construct. Flow id contention that luis mentioned above comes when you use a specific flow-id to dump stats in operational data store for rpc installed flows, but user uses the same

Re: [openflowplugin-dev] ovs nsh patches are available for public use

Hi Yang, Thanks for this effort. It would be great if you can share the output of "sudo ovs-vsctl show" & "sudo ovs-ofctl show" Thanks Vikram From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Yang, Yi Y Sent: Friday, April 15,

Re: [openflowplugin-dev] [sfc-dev] [opnfv-tech-discuss] ovs nsh patches are available for public use

This is super interesting guys. @Brady, cannot we configure such scenario currently with ODL SFC?? [image: Test Network Topology] Correct me if I'm wrong, but If we manage to create this scenario using ETH+NSH between the SFF and the SF, we are stepping aside the VxLAN issue and the workaround

Re: [openflowplugin-dev] [opnfv-tech-discuss] [sfc-dev] ovs nsh patches are available for public use

A few more questions now that Ive started looking into this: I notice you're using Eth+NSH encapsulation between the SFF and SF, but VXLAN-GPE + NSH between the SFFs. With your patch, can we use VXLAN-GPE+NSH between the SFF and SF? I guess we wont be able to use your patch with the current

Re: [openflowplugin-dev] [sfc-dev] ovs nsh patches are available for public use

Yang, Thanks for this! We'll start looking into using this now. Do you know what's the latest status of getting NSH into OVS officially? What's the difference between this patch in your github and what will be available officially? What are the system requirements for using your patch,

[openflowplugin-dev] ovs nsh patches are available for public use

Hi, folks We have pushed ovs nsh patches in https://github.com/yyang13/ovs_nsh_patches, you can follow instructions in README.md to apply these patches and build ovs to support nsh, please let me know if you have any problem during using. ___

Re: [openflowplugin-dev] Change in integration/test[master]: Added test suites for cluster HA data recovery leader follow...

Hi Luis I tested the same script several times with OVS 2.3.2 it is executing fine, all resync works perfectly fine but I see issue (resync failure after leader or follower restart) when I run via OVS 2.4.0. Thanks Sanjib -Original Message- From: Gerrit Code Review