On Fri, Jun 29, 2018 at 1:03 AM Robert Varga <[email protected]> wrote:

> Hello everyone,
>
> I have staged upgrades to NMDA versions of the above models here:
> https://git.opendaylight.org/gerrit/73593
> https://git.opendaylight.org/gerrit/73594
>
> NMDA stands for Network Management Datastore Architecture and is defined
> in RFC8342. The gist of it is that there is clear distinction between
> data stores -- adopting MD-SAL's approach to storing data. The end
> result is that the config and oper trees now share the same hierarchy,
> with no pesky -state top-level container.
>
> This is a major improvement over current models and I believe we should
> adopt it as quickly as feasible.
>
> ietf-interfaces directly impacts:
> bgpcep
> genius
> lispflowmapping
> netvirt
>
> ietf-ip directly impacts:
> lispflowmapping
> sfc
>
> Can we discuss what the actual impacts would be and perhaps agree on an
> upgrade timeline (next release perhaps)?
>

In order not to depend on an unmanaged project, we copied the v3po.yang
model (which imports ietf-interfaces and ietf-ip) from the honeycomb/vbd
project to lispflowmapping. I think in sfc the dependency on
ietf-interfaces and ietf-ip is due to the same model. This is far from
ideal, and it would probably be wise to have both managed and unmanaged
project synchronize the upgrade. I can test if simply changing the
dependencies in the POM files to the newly introduced artifacts causes any
build issues (v3po.yang doesn't import a particular revision of
ietf-interfaces.yang and ietf-ip.yang), but there may be other effects,
especially in terms of interoperability with VPP, so this needs careful
consideration.

If we start to actively work on the transition now, next release sounds
realistic to me.

-Lori


>
> Thanks,
> Robert
>
> _______________________________________________
> TSC mailing list
> [email protected]
> https://lists.opendaylight.org/mailman/listinfo/tsc
>
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Reply via email to