I think in the case of OFP the work can be split in 2: - Update topology model to last RFC (same as other projects in ODL). To me the sooner we can do this the better. This also may have reduced impact in OFP apps because the topology model contains very few data (e.g. no specific OFP extensions were added to original topology model)
- Migrate OFP inventory to topology. This will be more work and have more impact for sure because most (if not all) OFP apps look at the inventory for anything to do with OpenFlow. Now I am not sure what is the hurry here because inventory model is only used by OFP in ODL so at least there is no ODL integration concern AFAICT. BR/Luis > On Sep 5, 2019, at 11:19 AM, Robert Varga <n...@hq.sk> wrote: > > [+ discuss, mdsal-dev] > > On 05/09/2019 19:24, Anil Vishnoi wrote: >> As for the next steps, I think we need to migrate these models to >> openflowplugin, where they can be maintained, as that world is the only >> place that really uses them. >> >> As far as upstream OpenDaylight is concern this make sense to me, but we >> need to be careful about the downstream consumer. Downstream user who >> just use core ODL projects (Controller, yangtools, mdsal,aaa) to develop >> their standalone application might be using these models, so this >> movement will break them and to solve this they will have to put >> dependency on openflowpluing, which they might not want. > > That is a valid concern, yes. > > The answer really lies in packaging, as if you are using karaf, you will > have openflowplugin-features added to you distribution. Those would not > be installed, but will bloat the distro & confuse the users. > > On the other hand, every feature we build is a separate repository, so > while you'd depend on openflowplugin-artifacts, you do not have to > depend on openflowplugin-features -- I think. > > Without Karaf, you depend on whatever you like, so yeah, you get tied up > with OFP release cycle, but other than that there should not be a problem. > > As far as those models are concerned, platform (mdsal/controller/netc) > position on them can be summed up as: > > Migrate to using ietf-network(-topology), which are shipped from MD-SAL > for a year now. There are RFC8345 standard and are not expected to make > in the foreseeable future. > As a further note, while performing that migration, also move away from > using yang-ext.yang routed RPCs by switching to YANG 1.1 actions. Such > models are not supported by legacy RESTCONF (which itself is > deprecated), but are fully supported by RFC8040 RESTCONF (which is the > only actively supported version). > > On a related note, this discussion will also be coming up with relation to: > > ietf-packet-fields > ietf-access-control-list > ietf-lisp-address-types > ietf-ted > ietf-topology > ietf-topology-isis > ietf-topology-l3-unicast-igp > ietf-topology-ospf > > as MD-SAL will be gradually dropping at least those, which have been > superseded by RFCs. > > Regards, > Robert > > _______________________________________________ > Discuss mailing list > Discuss@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________ Discuss mailing list Discuss@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/discuss
