December 2019 - dev - lists.frrouting.org

Regarding support for rsvp-te support in free routing
by Rhene Kavi 20 Feb '20

20 Feb '20

Hi All, Do we have any plans to support rsvp-te Thanks in advance KaviRhene

4 3

Re: [dev] ask on mailing list
by Phil Wiggins 31 Dec '19

31 Dec '19

It's available already in Ubuntu 19.04 as a package for multiple architectures. https://packages.ubuntu.com/search?keywords=frr&searchon=names&suite=all&se… disco (19.04) <https://packages.ubuntu.com/disco/frr> (net): FRRouting suite of internet protocols (BGP, OSPF, IS-IS, ...) [*universe*] 6.0.2-2: amd64 arm64 armhf i386 ppc64el s390x Cheers, Phil On Mon, 30 Dec 2019 at 22:27, Mike Mazarick < mike.mazarick(a)virtudatacenter.com> wrote: > I am running Ubuntu 19.04 (disco) and would like to try out frr. > > > > Mike Mazarick > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev >

1 0

ask on mailing list
by Mike Mazarick 31 Dec '19

31 Dec '19

I am running Ubuntu 19.04 (disco) and would like to try out frr. Mike Mazarick

1 0

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

18 Dec '19

All, Today we discussed and concluded on how we should proceed with VRF for protocols. 1. IETF yang models are bit complex to handle VRF and need to do lot of deviation and augmentation. 2. We will move on with private yang for protocols with type and vrf_name as the key. 3. Protocol will have a leafref to VRF. 4. Current FRR-VRF need more leaf w.r.t RD and RT. 5. VRF being leafref means VRF configuration should come first for majority of protocols, but this rule will be relaxed in some cases where IP route nexthop is pointing to next table. 6. Agreed to amend existing PR with new way of VRF. A.I : Santosh/Vishal 1. With the new VRF and protocol models agreed, check if all VRF configuration can fit in. 2. Come up with mapping table of VRF config to Yang data model. Thanks Santosh P K

1 0

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

18 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 13 Dec '19

13 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 13 Dec '19

13 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 13 Dec '19

13 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