Renato, Thanks a lot for quick check on this. I guess that would be our last option. Thanks Santosh P K On 14/12/19, 2:46 AM, "Renato Westphal" <renato@opensourcerouting.org> wrote: On Fri, Dec 13, 2019 at 3:15 PM Santosh P K via dev <dev@lists.frrouting.org> wrote: > > > > > ---------- Forwarded message ---------- > From: Santosh P K <sapk@vmware.com> > To: FRRouting-Dev <dev@lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 13 Dec 2019 18:14:26 +0000 > Subject: Northbound changes discussion - MOM 13/12/2019 > > Hello All, > > Below are the points discussed and concluded in today’s meeting. > > > > Discussion: > > Went over static yang model that has addressed last week comments. > Currently static yang has its own nexthop defined as we could not use nexthop defined in frr-nexthop.yang. > > Frr-nexthop.yang is having only groupings and this would not help for other modules to extend/deviate the same. > Frr-nexthop.yang should be changed and static should make use of the same. > > Code for handling nexthop-group should be part of the library which right now is sitting under zebra so that all the other modules can leverage it. > > Mark may have plans for making it a library. > > Port only required IETF yang files in separate PR categorized per protocols. > Discussed on VRF and how should this be used. > > Discussed over network instance defined in IETF. Discussed over restrictions of network-instance in libyang. > Renato will be trying with deviation and see if we can get a workaround for this problem. Just checked and this won't be possible unfortunately. YANG deviations can only be used to change properties of a target node, they can't be used to transform a container into an augmentation for instance. In that case, what we can do is to have modified versions of IETF modules in our tree (like other people suggested). We would only need to name them differently to make it explicit they are not the original IETF modules. In the future, once support for schema mount is integrated into libyang, we can get rid of this hack and "migrate" to the original IETF modules. This is just one possibility, more discussions need to be done about this. Cheers, Renato. > Lou suggested to use network instance manually. > > > > Conclusion: > > Agreed to change the exiting frr-nexthop.yang to have common container of nexthop and nexthop-groups. Have only minimum set of leaf which are common across all the modules. Augment/deviate this in protocols as they need. > > > > > > We will meet again on Wednesday 18th Dec 2019 at 8:00AM PST for VRF discussion. > > > > > > Thanks > > Santosh P K > > > > > ---------- Forwarded message ---------- > From: Santosh P K via dev <dev@lists.frrouting.org> > To: FRRouting-Dev <dev@lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 13 Dec 2019 10:15:02 -0800 (PST) > Subject: [dev] Northbound changes discussion - MOM 13/12/2019 > _______________________________________________ > dev mailing list > dev@lists.frrouting.org > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frrouting.org%2Flistinfo%2Fdev&data=02%7C01%7Csapk%40vmware.com%7C963c02f8a6a048894ad008d78011bcb5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118685986619406&sdata=YhfPcBLuEXGIYwI9ECY4i2mp09gzk6pWPEGaZEpa9AM%3D&reserved=0 -- Renato Westphal