[dev] Fwd: EIGRP
rzalamena at opensourcerouting.org
Fri Jun 12 19:58:00 UTC 2020
Re sending to list.
---------- Forwarded message ---------
From: Rafael Zalamena <rzalamena at opensourcerouting.org>
Date: Fri, Jun 12, 2020 at 1:58 PM
Subject: Re: [dev] EIGRP
To: Quentin Young <qlyoung at cumulusnetworks.com>
Cc: FREIVALD, JOSEPH A <jf1578 at att.com>, dev at lists.frrouting.org
<dev at lists.frrouting.org>
On Fri, Jun 12, 2020 at 1:20 PM Quentin Young
<qlyoung at cumulusnetworks.com> wrote:
> Hi Joseph - sounds like some cool work.
> Is this based on the EIGRP implementation we currently have, or is this implemented from scratch?
> >Are there any defects in the 5.0 implementation of BFD that I should be aware of and/or backport BFD fixes from 7.2?
> Rafael is likely the best person to answer that in specifics, but seeing as there's well over 7000 commits to FRR since 5.0, at least 224 of which are in BFD, the answer is almost certainly yes.
> Any particular reason you chose to stay based on the 5.0 branch?
I don't think BFD protocol integration has changed much (the
`lib/bfd.h` part), if we are only talking about integration.
Since 5.0 I can think of four big changes:
- Added support for Control Plane Independent bit (by Philippe Guibert
- Added VRF support: allow a instance to create session in multiple
VRFs (also from Phillipe)
- Some daemons have BFD integration command using northbound (e.g. YANG models)
- (not commited yet) a separated function to replace the old zebra
talking function (see PR https://github.com/FRRouting/frr/pull/6437 ),
the old one should still works ( see bfd_peer_sendmsg )
When you fast-forward to `master` you'll probably only need to adjust
function call to include extra parameters (or change for the new
The BFD daemon code itself otherwise has gone through heavy changes,
but protocol integration has seen very little change since we keep
compatibility with ptm-bfd (Cumulus External daemon). It will only be
a problem if you want to modify BFD daemon code.
I think the biggest challenge of implementing eigrp in FRR 5.0 is the
lack of northbound support. We already have EIGRP YANG models and
working CLI using northbound in newer versions.
> >Is there any interest in including EIGRP in the full FRR feature set?
> Yes, but we have an existing EIGRP implementation that is currently being worked on by others. Unfortunately, this development practice of creating whole features in private and then publishing them all at once has, time and again, proved very difficult to support for a collaborative free software project that moves as fast as we do :(. In any case we'd certainly be interested in the code to see what can be done.
I agree... Maybe we should write some more literature educating people
to slowly integrate required code before merging a big feature (avoid
the all-or-nothing and rebase-hell problems).
> P.s. I suggest you join our public slack if you'd be interested in chatting with the other folks working on EIGRP in FRR.
More information about the dev