March 2018 - dev - lists.frrouting.org

ISIS 3-way Handshake has been Implemented
by Donald Sharp 14 Mar '18

14 Mar '18

All - I would like to thank Christian Franke for implementing ISIS 3-way handshake as per RFC 5303. This code is currently available on master for using. To disable this option please use `no isis three-way-handshake` under an interface you would not like to use it on. thanks! donald

1 0

Integrating DLEP with FRR
by Susheela Francis 09 Mar '18

09 Mar '18

Hi, I am trying to integrate an open source DLEP stack with FRR/Quagga. I am trying to manipulate the linux kernel routing table to include the DLEP routes in its routing table and then redistribute it to Quagga. I am new to this and have not been successful in doing this so far. Can you suggest a way ahead? Is there a better approach to solve this problem? Thanks & Regards, Susheela Francis Larsen & Toubro ltd. Larsen and Toubro Limited; L&T Heavy Engineering | Strategic Electronics Center "Komarla Solitaire", 145/2, Old Madras Road, CV Raman Nagar, Bangalore 560093 Tele: +91-80-6693 6245, Mobile: +91-8105228297 Mail: SUSHEELA.FRANCIS(a)LARSENTOUBRO.COM<mailto:SUSHEELA.FRANCIS@LARSENTOUBRO.COM> Web: www.lthed.com<http://www.lthed.com/>; www.larsentoubro.com<http://www.larsentoubro.com/>; Larsen & Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

4 8

Today's Technical Meeting Notes
by Donald Sharp 06 Mar '18

06 Mar '18

1803- waiting of feedback of PR fixes issue 1810 - waiting for PR merge, perhaps also bring over to 4.0 1835 - Cumulus has solution to syslog as solution. Command line option is also possible. Phillippe will take lead on proposing a solution. ??? Doc reformat - Donald to work with Lou PBR - discussion on architecture and if have need for iptable management in FRR (to support PBR and flowspec, and to deconflict with VRFs/other table uses) . Probably need a rules manager as well. donald

1 0

Re: [dev] FRR Technical Meeting Notes - 02/27/2018
by Quentin Young 05 Mar '18

05 Mar '18

Forgot cc > On Mar 3, 2018, at 6:42 PM, Quentin Young <qlyoung(a)cumulusnetworks.com> wrote: > >> Okay from a practical standpoint I think this means that we have to support centos 6.x in new FRR releases until one year before the “Maintenance Updates” phase ends as we only support FRR release (even security fixes) for ~1 year. Right? > > Can you elaborate on how you drew that conclusion from this: > >>>> For whatever the platform in question is, we do the same thing. Continue to ship updated FRR packages for platforms in the “Full Updates” phase. Then once they enter the “Maintenance Updates” phase we freeze the package at whatever version it is, or close to it depending on convenience, and then only back port security fixes / critical bug fixes. > > I don’t think I understand your interpretation. > > Quentin > >> On Mar 3, 2018, at 5:49 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net>> wrote: >> >> Okay from a practical standpoint I think this means that we have to support centos 6.x in new FRR releases until one year before the “Maintenance Updates” phase ends as we only support FRR release (even security fixes) for ~1 year. Right? >> >> >> On 3/2/2018 12:45 PM, Lou Berger wrote: >>> >>> >>> >>> On 2/27/2018 2:49 PM, Quentin Young wrote: >>>> There’s two EOL dates in the table. Let’s not pretend that 1 of them is the ’true' EOL date. >>>> >>>> +---------------------+----------------------+ >>>> | Full Updates | May 10th, 2017 | >>>> +---------------------+----------------------+ >>>> | Maintenance Updates | November 30th, 2020 | >>>> +---------------------+----------------------+ >>>> >>>> Here is what I propose, since the majority of platforms follow something like the above, roughly: >>>> >>>> - “Full Updates” period, where packages are actively updated, new features, new kernels etc >>>> - “Maintenance Updates” i.e. only back porting security fixes / critical bug fixes >>>> >>>> For whatever the platform in question is, we do the same thing. Continue to ship updated FRR packages for platforms in the “Full Updates” phase. Then once they enter the “Maintenance Updates” phase we freeze the package at whatever version it is, or close to it depending on convenience, and then only back port security fixes / critical bug fixes. >>>> >>>> Does this sound reasonable to everyone? >>> At first glance, yes. >>> >>> But what does this really mean in practical terms, *we* don't expect to support an FRR release for more than say about year right? >>> >>> Are you saying we now need to keep old releases around for as long as we have a platform on which we're doing Maintenance Updates? (For example, 3.0 untilNovember 30th, 2020) >>> >>> What's your thinking / proposal here? >>> >>> Lou >>> >>> On Feb 27, 2018, at 2:31 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote: >>>>> >>>>> Right. It says: >>>>> Maintenance Updates2 <https://wiki.centos.org/About/Product#fndef-a91b3c0c287c782f9af063daff9e64b… <https://wiki.centos.org/About/Product#fndef-a91b3c0c287c782f9af063daff9e64b…>> November 30th, 2020 >>>>> >>>>> On February 27, 2018 2:20:24 PM Quentin Young <qlyoung(a)cumulusnetworks.com <mailto:qlyoung@cumulusnetworks.com> <mailto:qlyoung@cumulusnetworks.com <mailto:qlyoung@cumulusnetworks.com>>> wrote: >>>>> >>>>>> As Donald said in his email, >>>>>> >>>>>>>> We are just trying to match what the EOL is from the centos website itself. >>>>>> >>>>>> https://wiki.centos.org/About/Product <https://wiki.centos.org/About/Product> >>>>>> >>>>>>> On Feb 27, 2018, at 2:15 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote: >>>>>>> >>>>>>> fair point, based on a quick google: >>>>>>> >>>>>>> https://linuxlifecycle.com/ <https://linuxlifecycle.com/> >>>>>>> >>>>>>> CentOS 6 (released 10 Jul 2011, EOL 30 Nov 2020) >>>>>>> >>>>>>> Lou >>>>>>> >>>>>>> On 2/27/2018 2:01 PM, Donald Sharp wrote: >>>>>>>> Isn't that Redhat, not centos 6? Different distributions. We are >>>>>>>> just trying to match what the EOL is from the centos website itself. >>>>>>>> >>>>>>>> donald >>>>>>>> >>>>>>>> On Tue, Feb 27, 2018 at 1:34 PM, Lou Berger <lberger(a)labn.net <mailto:lberger@labn.net> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote: >>>>>>>>> Thanks for the notes! >>>>>>>>> >>>>>>>>> On 2/27/2018 12:56 PM, Quentin Young wrote: >>>>>>>>>> - Seeing as Centos 6 went EOL in May 2017, it is no longer supported; to >>>>>>>>>> be >>>>>>>>>> noted in docs >>>>>>>>> >>>>>>>>> umm, per https://access.redhat.com/support/policy/updates/errata <https://access.redhat.com/support/policy/updates/errata> >>>>>>>>> Linux 6, EUS 6.7 (ends December 31, 2018) >>>>>>>>> V6 End of Maintenance Support 2 (Product retirement): June 30, 2024 >>>>>>>>> >>>>>>>>> I know of a fair number of folks still using 6.x, I think EOL support is >>>>>>>>> premature. >>>>>>>>> I think FRR support is needed through *at least* the end of this year. >>>>>>>>> >>>>>>>>> Lou >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> dev mailing list >>>>>>>>> dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> <mailto:dev@lists.frrouting.org <mailto:dev@lists.frrouting.org>> >>>>>>>>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dev mailing list >>>>>>> dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> <mailto:dev@lists.frrouting.org <mailto:dev@lists.frrouting.org>> >>>>>>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev> >>>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> dev mailing list >>> dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> >>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>

2 1

FRR Technical Meeting Notes - 02/27/2018
by Quentin Young 03 Mar '18

03 Mar '18

*********************************************** FRR Technical Meeting Notes - February 27, 2018 *********************************************** Policy on support for EOL platforms ----------------------------------- - Should we support EOL platforms? Group consensus = No - Moving forward we will not explicitly support EOL platforms - Keep these platforms in CI, but remove as soon as it becomes inconvenient to maintain - Seeing as Centos 6 went EOL in May 2017, it is no longer supported; to be noted in docs Kernel minimum version requirement discussion --------------------------------------------- - What should our policy be on minimum kernel version needed for networking features? - Paul Z: Zebra should warn if a user tries to configure a feature and it's not supported - Martin W: `show features` command to inform user would be useful - Others: Agreed on both counts - Donald: If we implement the above, developers should be mindful when implementing kernel-specific features to update both of these things and it will be something to look for in future code reviews. Issues ------ Updates in individual issues. #1777, #1778 - Discussion postponed until Lou is present #1794 - General group consensus to stick with kernel style in this regard #1803 - Some people recall this being fixed in the past, Renato to take a look Pull Requests ------------- Updates in individual PRs. - #1711: Namespace VRF now in, thanks Philippe - #1704: Some packaging nits to fix, then good to go; ETA < 1 week Topotest PEP8 ------------- Martin & Rafael not too keen on reformatting whole codebase right now due to activity, but agree it might be worth looking at in the future. See further discussion here: https://github.com/FRRouting/topotests/issues/73#issuecomment-368952010

6 11