[dev] Northbound changes discussion - MOM 13/12/2019

[Jeff Tantsura]

+ 1 Renato

> On Dec 13, 2019, at 1:16 PM, Renato Westphal <renato at opensourcerouting.org> wrote:
> 
> On Fri, Dec 13, 2019 at 3:15 PM Santosh P K via dev
> <dev at lists.frrouting.org> wrote:
>> 
>> 
>> 
>> 
>> ---------- Forwarded message ----------
>> From: Santosh P K <sapk at vmware.com>
>> To: FRRouting-Dev <dev at 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 at lists.frrouting.org>
>> To: FRRouting-Dev <dev at 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 at lists.frrouting.org
>> https://lists.frrouting.org/listinfo/dev
> 
> 
> 
> -- 
> Renato Westphal
> 
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev