Re: [dev] Northbound changes discussion - MOM 13/12/2019
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://lists.frrouting.org/listinfo/dev
-- Renato Westphal
+ 1 Renato
On Dec 13, 2019, at 1:16 PM, 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://lists.frrouting.org/listinfo/dev
-- Renato Westphal
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
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
For meeting today below are the points we can discuss. 1. Yang mount support in libyang was asked late 2018 but there are no plans to get it done by 2019, not sure about plans in 2020 https://github.com/CESNET/libyang/issues/691. 2. Currently we have augmented routing protocols under VRF which is FRR defined. With this we cannot keep IETF name in Yang file since we have modified it and hence may need to change it. Disadvantage of this approach is that all the protocols are forced under VRF. 3. Do not edit IETF routing yang and augment routing with a leafref to VRF. With this currently we have type and name as the key for routing protocol list and name should be unique for each VRF in the list for same protocol. 4. Do not edit IETF routing yang and augment routing with leaf name to leafref to VRF. This we are still trying to see if we can really do this. Thanks Santosh P K On 15/12/19, 11:22 AM, "Santosh P K" <sapk@vmware.com> wrote: 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
participants (3)
-
Jeff Tantsura -
Renato Westphal -
Santosh P K