- dev - lists.frrouting.org

Next NetConf/Yang Meeting
by Donald Sharp 19 Dec '19

19 Dec '19

At the end of today's meeting we discussed what was next on our agenda: 1) Discussion of Zebra operational Model 2) Performance implications of data gathering for the operational model and how we want to tackle the issue 3) Central Server for dispatch ( not necessarily going to cover this but it's on the agenda ) 4) BGP netconf/yang Discussion ( We may have some questions here, as a placeholder if needed ) 5) The CLI transactional model has performance issues and how we want to approach this issue. Next meeting is this Friday at 11 EST, same meeting https://bluejeans.com/9192742159 donald

1 0

Re: [dev] Northbound changes discussion - MOM 13/12/2019
by Renato Westphal 18 Dec '19

18 Dec '19

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

3 3

Re: [dev] Northbound meeting (VRF discussion)
by Igor Ryzhov 15 Dec '19

15 Dec '19

Hi Santosh, I want to participate, but 18th Dec is not Friday. Can you, please, clarify the date. Regards, Igor On Fri, Dec 13, 2019 at 9:19 PM Santosh P K via dev <dev(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Santosh P K <sapk(a)vmware.com> > To: FRRouting-Dev <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 13 Dec 2019 18:18:06 +0000 > Subject: Northbound meeting (VRF discussion) > > Hello All, > > As discussed in meeting today. We will meet again at 8:00AM PST on > Friday 18th Dec 2019. Please use below link. > > > > https://bluejeans.com/9192742159 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> > > > > > > Agenda: > > 1. VRF usage for all yang models. > > > > Thanks > > Santosh P K > > > > > > ---------- Forwarded message ---------- > From: Santosh P K via dev <dev(a)lists.frrouting.org> > To: FRRouting-Dev <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 13 Dec 2019 10:19:39 -0800 (PST) > Subject: [dev] Northbound meeting (VRF discussion) > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev >

3 3

Northbound meeting (VRF discussion)
by Santosh P K 14 Dec '19

14 Dec '19

Hello All, As discussed in meeting today. We will meet again at 8:00AM PST on Friday 18th Dec 2019. Please use below link. https://bluejeans.com/9192742159<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Agenda: 1. VRF usage for all yang models. Thanks Santosh P K

1 0

Northbound changes discussion - MOM 13/12/2019
by Santosh P K 14 Dec '19

14 Dec '19

Hello All, Below are the points discussed and concluded in today’s meeting. Discussion: 1. Went over static yang model that has addressed last week comments. 2. 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. 3. 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. 4. Port only required IETF yang files in separate PR categorized per protocols. 5. 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. * Lou suggested to use network instance manually. Conclusion: 1. 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

1 0

Re: [dev] Next northbound meeting
by Lou Berger 14 Dec '19

14 Dec '19

Here are the references I mentioned in the meeting: - slide 7: https://datatracker.ietf.org/doc/slides-99-bess-03b-yang-lneni-impact-on-mv… - NI rfc: https://tools.ietf.org/html/rfc8529 - L3vpn model (using ni): https://tools.ietf.org/html/draft-ietf-bess-mvpn-yang-02 - L2vpn: https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-10 On 12/11/2019 5:29 PM, Santosh P K via dev wrote: > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

1 0

Interface mode ospf config not getting deleted opon unconfiguring ospf router
by Naveen K Suvarna 13 Dec '19

13 Dec '19

Hi, In FRR 7.2 OSPF, When ospf router is Unconfigured, interface mode ospf configurations are not getting deleted from running config. Is this behavior designed with any specific reason ? Example: router ospf ospf rouer-id 1.1.1.1 interface Ethernet8 ip ospf area 0 With above config, if I issue command “no router ospf”, interface level ospf configs will not get removed/deleted. Regards Naveen

2 5

Northbound changes discussion - MOM 12/12/2019
by Santosh P K 12 Dec '19

12 Dec '19

Hello All, Below are the points discussed and concluded in today’s meeting. Please correct me If I have missed or captured few conclusions not as we concluded. Discussion: 1. Use of nexthop as leaf ref. * FRR will have to satisfy nexthop being independent object and can be programed independently. * Currently kernel supports this feature and so does FRR with nexthop groups. 2. NULL0 attribute handling * We may not need NULL0 as this special nexthop and we should only provide blackhole interface. * Discussed about different type of interface avalible today in FRR. 3. FRR interface yang v/s IETF yang * Why was FRR interface yang defined while we could have used IETF yang and added augmented more leaf to it. * It was done as a placeholder and we will need to revisit it. 4. VRF usage * Discussed VRF usage for protocols. Should VRF be top of the tree or should be used as leafref. * Discussed different use of VRF being at top of tree and how it may help with configuration. 5. IETF data models usage * Use of IETF data models should not restrict any existing feature that FRR supports today. * We should try to use existing IETF data model with deviations. 6. We will conclude on Staticd review before PIM and IGMP data model. Conclusion: 1. Staticd Yang module will have leafref to nexthop. For this we need to deviate from IETF nexthop and have our own nexthop container defined. 2. Null0 is not required and providing blockhole is enough. 3. VRF should not be restricted on how it should be used with in FRR. It should be used as appropriate for a given protocol. We will meet again on Friday to discuss over the next review items and questions will be published beforehand. Thanks Santosh P K

1 1

Next northbound meeting
by Santosh P K 12 Dec '19

12 Dec '19

Hello All, As discussed in meeting today. We will meet again at 8:00AM PST on Friday 13th Dec 2019. The link for the meeting is as below. https://bluejeans.com/9192742159<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Agenda and topics to be discussed in upcoming meeting. 1. Review and conclude Static yang. 2. VRF usage conclusion. * We may not be able to use IETF network instance as currently libyang does not support mount option. * Making changes to existing IETF yang to allow VRF at top of the tree. 3. Port of all existing IETF Yang which could be used as is or with extensions in to FRR. * Interface yang. * Routing yang. * And so on. 4. Issues we encountered with libyang while using standard yang. * Currently if we are using ipv6-unicast-routing from IETF routing yang then libyang goes in a loop. * Remove few augment statements from rib-ext, as it is pointing to path which is not available in ietf-routing.yang Thanks Santosh P K

1 0

Odds and Ends from tech meeting
by Donald Sharp 11 Dec '19

11 Dec '19

All - 1) Dec 24 and Dec 31 meetings tech meetings are cancelled. 2) I plan to spend a bit of time on the Jan 7 meeting to allow us to have a bit of a retrospective. Please spend a few minutes thinking about what we've done well and what we've done poorly so we can discuss them in the meeting on the 7th. As always there is always room for improvement and we would love to hear the ideas 3) We plan to pull the next stabilization branch of FRR the week of Jan 5 as well. Please take a few minutes and help us get what is in PR now into the code base if you can. 4) One part of today's meeting centered around adding a new requirement for feature work in FRR. Namely all new Feature work *must* have a CI test that can be run the code to ensure it stays working as people make changes to how the underlying system works. Please be prepared to discuss this further and to see if we can come to a conclusion next week. thanks! donald

1 0