January 2019 - dev - lists.frrouting.org

Re: [dev] Open Network Equipment and FRRouting
by Hagen Woesner 21 Jan '19

21 Jan '19

Dear Łukasz, We (BISDN) have developed baseboxd, which is a netlink-to-OFDPA translator, and therefore works with FRR on whitebox switches, however there are of course still limitations in the number of platforms and supported features. For a number of Delta, Edge-core, Quanta, Celestica switches you can find ONIE images for download (http://repo.bisdn.de/pub/onie-testing/) and could try it out yourself. I hope this is not perceived as too much advertisement, after all it's free and Open Source, so I think it should be acceptable here. Documentation and code: https://www.basebox.org/ https://www.github.com/bisdn/basebox https://docs.bisdn.de Best regards, Hagen Am 21.01.19 um 17:04 schrieb Łukasz Wójcik via dev: > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev -- BISDN GmbH Dr.-Ing. Hagen Woesner Körnerstraße 7-10, 10785 Berlin, Germany mailto hagen.woesner(a)bisdn.de tel: +49 30 610816101 mobile: +49 160 7862096 www.bisdn.de Berlin Institute for Software Defined Networks - BISDN GmbH Managing Directors: Dr.-Ing. Hagen Woesner, Andreas Köpsel Commercial register: Amtsgericht Berlin-Charlottenburg HRB 141569 B VAT ID No: DE283257294 Corporate seat: Berlin

2 1

Open Network Equipment and FRRouting
by Łukasz Wójcik 21 Jan '19

21 Jan '19

Hello there, In the era of Open Networking equipment, e.g. switching ASICs support forwarding based on L3 information. I was wondering, if FRRouting supports or plans to support any mechanisms that would allow for passing L3 data to the hardware, and therefore offloading some work to the HW ? I would imagine some kind of API or event-driven mechanisms that would require HW manufacturer's SDKs/API to glue-to/plug-into FRRouting ? Best regards, -ŁW

2 2

Slack access request
by jipan yang 16 Jan '19

16 Jan '19

Hi, I would like to join the slack channel for FRR development. Can someone help me with an invite? Thanks Jipan

2 1

Re: [dev] FRR North bound API
by Philippe Guibert 16 Jan '19

16 Jan '19

Hi Mohammed, Thanks for your interest in the interaction between ODL and FRR proposal. I showed the two drawings, to try to identify the gap between that design and the current FRR. About #2585, this is an unrelated feature request. This was for substituting the ZAPI interface with gRPC. This is different in our case; In our case, we look for having a gRPC northbound API. Concretely, instead of vty, this would be gRPC. The fact is that at first sight, I was thinking that the first drawing was the only solution to be accepted. Actually, the more I look with solution, the more I think there is yet a gap. I can expose you the gaps that I identified with solution 1. o There is first an issue in the drawing, that mixes both FIB and RIB. Currently, the remote dataplane plugin is able to configure remote-dataplane as FIB. So, one could imagine having a dataplane plugin extension as Southbound interface equipped with gRPC. The reverse is not possible; this is not ZEBRA FIB is configurable, but ZEBRA RIB. That implies that an other plugin extension as Northbound interface equipped with gRPC should be made. This would either be located in Zebra, or in a separate daemon. o The second issue is that ODL, when configuring the BGP layer, handles some pure BGP concepts. For instance, Route Distinguisher is a pure BGP concept. Injecting entries in a non BGP instance would mean that we hardcode the relationship between VRF and RD. This would mean that ODL, when injecting route entries, would inject per-VRF route entries, and not per-RD route entries. As other example, End-of-RIB is something handled after having injected a whole series of prefixes. This is a BGP marker that informs the protocol about the termination of the route entries. This is useful on graceful restart scenarios. Those concepts are internal to BGP, as far as I know. Using those marker outside of BGP will require some work. o The third issue is related to the Zebra layer. Having a remote dataplane plugin is not enough. Some BGP information is kept on BGP only, and never goes to ZEBRA layer. Because ODL acts as the real dataplane configurator, ODL today has not really the need to rely on ZEBRA layer. However, having remote dataplane will require some extensions to ZEBRA. For instance, some EVPN entries are not exported to the correct VRF. Actually, like the first proposal, the second drawing takes reuses gRPC and yang based approach, thus facilitating the interoperability work between ODL and FRR. Adding to this, the second drawing does not have the 3 above issues. The configuration of BGP route entries would be done by using BGP. Also the update of BGP route entries would be done by registering to yang nodes. Mohammed, Now that I exposed you the main problems of the first drawing, what is your opinion about the concrete solutions that should be applied ? Thanks, Philippe On Mon, Jan 14, 2019 at 3:57 PM Mohammed Anzal K via dev <dev(a)lists.frrouting.org> wrote: > > > > > ---------- Forwarded message ---------- > From: Mohammed Anzal K <mohammeda(a)altencalsoftlabs.com> > To: dev(a)lists.frrouting.org > Cc: > Bcc: > Date: Mon, 14 Jan 2019 20:26:04 +0530 > Subject: Re: [dev] FRR North bound API > Hi Philippe, > > Thanks for your inputs. > > I am also interested in the use case of L3VPN/L2VPN for ODL-FRR interaction. > > I would root for the approach mentioned by you in the first slide, of interfacing the zebra daemon for prefix handling, to ODL over gRPC. > > Meanwhile, when are we planning to start with the bgpd specific north bound API related work ? > > Is there any planned timeline for this feature request #2585 - gRPC support for Zebra > > Thanks > > Anzal > > On 19-12-2018 08:34 PM, Philippe Guibert wrote: >> >> Hi Anzal, >> >> About your question related to ODL-FRR interaction, may I know if you >> have a specific ODL service in mind ? >> >> I have come up with design proposals on ODL/FRR interaction for L3VPN >> and L2VPN in ODL service. >> Main points are: >> - rely on the new yang NB API ( using GRPc technology). >> - optional : extend L3VPN/L2VPN to Zebra, via remote dataplane >> >> You can find specific proposal in [0] >> >> Anzal, or everyone else in the FRR community, >> your comments are welcome, >> >> Thanks, >> >> Philippe >> >> [0] https://docs.google.com/presentation/d/18LkCGc8HAXto-c5IRT0NUBLmKRBYM6Oq6D5… >> >> On 11/21/18, Jeff Tantsura <jefftant(a)gmail.com> wrote: >>> >>> Hi, >>> >>> Netconf is a configuration protocol and is not particularly suitable for >>> streaming data, one could use >>> YANG-push(https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20), has >>> been implemented in ODL’ Baron release >>> (https://docs.opendaylight.org/en/stable-boron/user-guide/yang-push.html) >>> however - general performance implications apply, >>> gRPC on another hand is de-facto industry standard for streaming telemetry >>> OpenConfig has defined number of frameworks. >>> Specifically for prefix injection, gRIBI >>> (https://github.com/openconfig/gribi/blob/master/doc/motivation.md) could be >>> considered, this what we (IETF) envisioned with I2RS effort but, reality is >>> different. >>> >>> Cheers, >>> Jeff >>> >>> >>>> On Nov 17, 2018, at 12:26 AM, Philippe Guibert >>>> <philippe.guibert(a)6wind.com> wrote: >>>> >>>> Hi Anzal, >>>> >>>> I agree with your proposal, with some concerns however. >>>> >>>> I presented a few weeks ago at FRR weekly meetings, some slides about >>>> what would be the mechanisms involved for an SDN controller to be able >>>> to use FRR as BGP speaker. ODL can be the target, obviously. See in >>>> [0] >>>> >>>> The yang solution applied to BGP northbound API has been proposed. >>>> >>>> However, there were two remarks: >>>> - on the data exchanged between SDN and FRR. >>>> What was ok was for configuration ( BGP, VPN, BGP peers, ...), since >>>> it fits well with BGP NB API. >>>> >>>> However, at one moment, SDN had to populate the IPs information coming >>>> from its VMs. The best solution was to use an other API plugged into >>>> ZEBRA ( and not BGP), so that this IP information could be seen as a >>>> remote dataplane. Here, the API is not well defined yet. Should this >>>> API be equipped with Yang too? >>>> >>>> - on the constraints between SDN and FRR. Some API require performance. >>>> For instance, will yang fit well when SDN retrieves thousands of >>>> prefix entries ? >>>> >>>> Remember that if you use a netconf server like netopeer, the data flow >>>> will look like the below: >>>> odl client <---> netopeer server <---> sysrepo server <---> bgp/zebra >>>> server >>>> >>>> which may not be the optimised path when you want to retrieve a lot of >>>> prefix entries. to be confirmed. >>>> >>>> There is an alternative. From document [1], figure 2 depicts a new NB >>>> API that bypasses sysrepo, and relies on scripts (it looks like a data >>>> format ( gRPC with protoBuf) carried close to sysrepo bgp data >>>> exchanges ( using protobuf) could be used to exchange with routing >>>> daemons. >>>> Because that path would bypass netopeer and sysrepo, while keeping a >>>> data format close to what is done with netconf ( though not all would >>>> be possible), retrieving prefix entries ( and why not configuration >>>> too) could be optimised. Here too, that path has to be confirmed. >>>> Which technology could suit well with FRR (also from licensing point >>>> of view..). >>>> >>>> Philippe >>>> >>>> [0] >>>> https://docs.google.com/presentation/d/194vUFaWxmhfTpHyANHsP66Ffw0BQuJ9sI0i… >>>> [1] https://github.com/opensourcerouting/frr/wiki/Architecture >>>> On Thu, Nov 15, 2018 at 1:59 PM anzal <mohammedanz(a)gmail.com> wrote: >>>>> >>>>> Hi >>>>> >>>>> @Renato Westphal >>>>> "https://github.com/opensourcerouting/frr/wiki/Architecture" >>>>> >>>>> Can this not be used to manage, configure and get updates from the FRR >>>>> routing daemons by an external NETCONF device, say an SDN controller ? >>>>> >>>>> Like ODL has a south bound Netconf - >>>>> https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guid… >>>>> >>>>> So by using this I think ODL would be able to configure and get prefix >>>>> updates from the signalling daemons in FRR. Correct me if I am wrong >>>>> here. >>>>> >>>>> Thanks >>>>> >>>>> _______________________________________________ >>>>> dev mailing list >>>>> dev(a)lists.frrouting.org >>>>> https://lists.frrouting.org/listinfo/dev >>>> >>>> _______________________________________________ >>>> dev mailing list >>>> dev(a)lists.frrouting.org >>>> https://lists.frrouting.org/listinfo/dev >> >> _______________________________________________ >> dev mailing list >> dev(a)lists.frrouting.org >> https://lists.frrouting.org/listinfo/dev > > > > > > ---------- Forwarded message ---------- > From: Mohammed Anzal K via dev <dev(a)lists.frrouting.org> > To: dev(a)lists.frrouting.org > Cc: > Bcc: > Date: Mon, 14 Jan 2019 06:57:46 -0800 (PST) > Subject: Re: [dev] FRR North bound API > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

2 1

Hello FRR!
by Dino Farinacci 15 Jan '19

15 Jan '19

Hey folks, I just joined this list since I got word there is interest implementing LISP in FRR (thanks Jeff). If there is anything I can do to assist, please let me know. My interest is to make sure the FRR implementation is spec compliant and can interoperate with my lispers.net implementation. Also, I am available for helping out with LISP FRR deployments and can provide mapping system infrastruture for your testing. Is there any kind of schedule? How many people are committing to the implementation effort? Just a few starter questions. Thanks, Dino

2 1

FRR North bound API
by anzal 14 Jan '19

14 Jan '19

Hi @Renato Westphal "https://github.com/opensourcerouting/frr/wiki/Architecture " Can this not be used to manage, configure and get updates from the FRR routing daemons by an external NETCONF device, say an SDN controller ? Like ODL has a south bound Netconf - https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guid… So by using this I think ODL would be able to configure and get prefix updates from the signalling daemons in FRR. Correct me if I am wrong here. Thanks

4 6

Slack access request
by Mohammed Anzal K 14 Jan '19

14 Jan '19

Hi, I would like to join the slack channel for FRR development. Can someone help me with me an invite for this ? Thanks Anzal

1 1

New Releases of FRR
by Donald Sharp 11 Jan '19

11 Jan '19

All - On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit: https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a8… We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here: https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2 Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately. At this point we are applying for a CVE and will announce that information when we have it. In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias. thanks! donald

2 4

Can you please invite me to slack
by Matthias Cramer 08 Jan '19

08 Jan '19

Hi Can you please invite me to frrouting.slack.com Thanks. Regards Matthias

2 1

Request access to slack channel
by Xiaodong Xu 08 Jan '19

08 Jan '19

Hi Channel Operators, Can I join slack channel for FRR development? Thanks. Regards, Xiaodong

2 1