Networking-odl will not consume ODL-SFC directly. Neutron northbound project already have yang models based on networking-sfc API's (flow-classifier and sfc api) and networking-odl just passthrough the networking-sfc API to neutron northbound. I am currently working on the translation layer that converts the networking-sfc yang models ( flow classifier, sfc) to net-virt-sfc classifier and odl-sfc yang models.
Sam and I discussed about this few days ago and we thought we probably can think of migrating netvirt-sfc to new net-virt code, and probably migrate it to use Genius as well, but that depends on the time and bandwidth and looking at remaining time, it is not in favor. Given that it's very late in the cycle, in my opinion, it would be good if we can defer the migration of SFC to Genius for the Carbon release. Thoughts? On Fri, Jul 22, 2016 at 7:53 AM, Andre Fredette <afrede...@redhat.com> wrote: > Yes, changes in networking-sfc would be needed, or another approach would > be needed -- hence my comment about the unknown timing. Until that's all > worked out, the plan is to stick with the current model/APIs. > > Andre > > > On Fri, Jul 22, 2016 at 9:36 AM, Brady Allen Johnson < > brady.allen.john...@ericsson.com> wrote: > >> >> Andre, >> >> I dont think networking-sfc will be able to communicate with ODL SFC >> until they change their data models to be compliant with IETF SFC. >> >> Brady >> >> >> >> On 22/07/16 15:09, Andre Fredette wrote: >> >> Juanma, >> >> Someone else on the list can correct me if they think otherwise, but I >> don't think it will be in Boron. The API question is a good one. There is >> also an effort getting started to change Tacker so that instead of talking >> directly to ODL, it communicates via networking-sfc and networking-odl. >> This would likely result in some API changes, but I don't know about the >> timing of things right now. >> >> Andre >> >> >> On Fri, Jul 22, 2016 at 8:34 AM, Juan Manuel Fernandez < >> juan.manuel.fernan...@ericsson.com> wrote: >> >>> Thanks Andre! >>> >>> >>> >>> Do you know if the plan is having it in Boron? >>> >>> >>> >>> When adding this SFC support, will VPN Service-based Netvirt keep old >>> Netvirt REST API? >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Juanma >>> >>> >>> >>> *From:* Andre Fredette [mailto:afrede...@redhat.com] >>> *Sent:* viernes, 22 de julio de 2016 13:54 >>> *To:* Juan Manuel Fernandez <juan.manuel.fernan...@ericsson.com> >>> *Cc:* Sam Hague <sha...@redhat.com>; Brady Allen Johnson < >>> brady.allen.john...@ericsson.com>; Dayavanti Gopal Kamath < >>> dayavanti.gopal.kam...@ericsson.com>; netvirt-...@lists.opendaylight.org; >>> sfc-dev@lists.opendaylight.org >>> *Subject:* Re: [sfc-dev] [netvirt-dev] Integration App Coexistence >>> without using Genius >>> >>> >>> >>> Juanma, >>> >>> The plan is to add SFC support to the new VPN Service-based NetVirt, >>> which is using Genius. We're not planning to change the implementation in >>> the old NetVirt at this time. >>> >>> Andre >>> >>> >>> >>> On Fri, Jul 22, 2016 at 5:13 AM, Juan Manuel Fernandez < >>> juan.manuel.fernan...@ericsson.com> wrote: >>> >>> Hi, >>> >>> >>> >>> Just one clarification on my questions below, I do not mean whether SFC >>> Classifier in Netvirt is ported to Genius project, but whether SFC >>> Classifier in Netvirt is ported to use Genius. >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Juanma >>> >>> >>> >>> *From:* netvirt-dev-boun...@lists.opendaylight.org [mailto: >>> netvirt-dev-boun...@lists.opendaylight.org] *On Behalf Of *Juan Manuel >>> Fernandez >>> *Sent:* viernes, 22 de julio de 2016 10:59 >>> *To:* Sam Hague <sha...@redhat.com>; Brady Allen Johnson < >>> brady.allen.john...@ericsson.com>; Dayavanti Gopal Kamath < >>> dayavanti.gopal.kam...@ericsson.com> >>> *Cc:* netvirt-...@lists.opendaylight.org; sfc-dev@lists.opendaylight.org >>> *Subject:* Re: [netvirt-dev] [sfc-dev] Integration App Coexistence >>> without using Genius >>> >>> >>> >>> Hi, >>> >>> >>> >>> I guess that means SFC Classifier in Netvirt is not ported to Genius in >>> Boron, are you thinking on porting it in Carbon? I’ve seen some Netvirt >>> architecture slides talking about a possible integration of ACL service >>> (which to my understanding is making use of Genius) with SFC, is my >>> understanding correct? When that would happen? >>> >>> >>> >>> In SFC we are working on integrating SFC with Genius and the idea was >>> having it for Boron. I guess we might find some incompatibilities between >>> SFC using Genius and SFC Classifier in Netvirt. Netvirt, SFC, what is you >>> view on that? >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Juanma >>> >>> >>> >>> *From:* sfc-dev-boun...@lists.opendaylight.org [ >>> mailto:sfc-dev-boun...@lists.opendaylight.org >>> <sfc-dev-boun...@lists.opendaylight.org>] *On Behalf Of *Sam Hague >>> *Sent:* miércoles, 20 de julio de 2016 21:36 >>> *To:* Brady Allen Johnson <brady.allen.john...@ericsson.com> >>> *Cc:* netvirt-...@lists.opendaylight.org; sfc-dev@lists.opendaylight.org >>> *Subject:* Re: [sfc-dev] Integration App Coexistence without using >>> Genius >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jul 20, 2016 at 12:55 PM, Brady Allen Johnson < >>> brady.allen.john...@ericsson.com> wrote: >>> >>> >>> I have a question about the Netvirt and SFC integration that we did in >>> Beryllium and how it will be affected by the Netvirt integration with >>> Genius. >>> >>> In Beryllium, we implemented application coexistence by using table >>> offsets and sharing table=0. Now, in Boron, Genius will take care of the >>> application coexistence, but Im not sure how complete the SFC integration >>> with Genius will be in Boron. So, if SFC is not integrated with Genius in >>> Boron, will the Netvirt/SFC integration/AppCoexistence stop working? >>> >>> The old netvirt using the coexistence impl is still there so you can >>> continue to use that feature as is. >>> >>> >>> Regards, >>> >>> Brady >>> >>> _______________________________________________ >>> sfc-dev mailing list >>> sfc-dev@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/sfc-dev >>> >>> >>> >>> >>> _______________________________________________ >>> sfc-dev mailing list >>> sfc-dev@lists.opendaylight.org >>> https://lists.opendaylight.org/mailman/listinfo/sfc-dev >>> >>> >>> >> >> >> > > _______________________________________________ > netvirt-dev mailing list > netvirt-...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/netvirt-dev > > -- Thanks Anil
_______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
