[vpp-dev] Published: FD.io CSIT-2005 Release Report

Hi All, FD.io CSIT-2005 report has been published on FD.io docs site: https://docs.fd.io/csit/rls2005/report/ Many thanks to All in CSIT, VPP and wider FD.io community who contributed and worked hard to make CSIT-2005 happen! See below for pointers to specific sections in the report. Welco

Re: [vpp-dev] [tsc] Published: FD.io CSIT-2005 Release Report

Congratulations to all! -daw- On 7/14/2020 9:33 AM, Maciek Konstantynowicz (mkonstan) via lists.fd.io wrote: Hi All, FD.io CSIT-2005 report has been published on FD.io docs site: https://docs.fd.io/csit/rls2005/report/ Many thanks to All in CSIT, VPP and wider FD.io community who contri

Re: [vpp-dev] Published: FD.io CSIT-2005 Release Report

Congrats! That was an excellent job done ! --a > On 14 Jul 2020, at 15:33, Maciek Konstantynowicz (mkonstan) via lists.fd.io > wrote: > > Hi All, > > FD.io CSIT-2005 report has been published on FD.io docs site: > >https://docs.fd.io/csit/rls2005/report/ > > Many thanks to All in CSIT,

Re: [vpp-dev] Replacing master/slave nomenclature

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding. Steven On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via lists.fd.io" wrote: +1, especially since our next release will be supported for a year, and API name chan

Re: [vpp-dev] Replacing master/slave nomenclature

Hi Steven, Please note that per this proposition, https://lkml.org/lkml/2020/7/4/229, slave must be avoided but master can be kept. Maybe master/member or master/secondary could be options too. Jerome Le 14/07/2020 18:32, « vpp-dev@lists.fd.io au nom de steven luong via lists.fd.io » a écri

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

This is a pretty good summary of various suggestions for replacement terms: https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/ Ed On Tue, Jul 14, 2020 at 11:36 AM Jerome Tollet via lists.fd.io wrote: > Hi Steven, > Please note that per this p

Re: [vpp-dev] Replacing master/slave nomenclature

It is subjective and contextualized. But in this case, if making the effort to correct a wrong, why stop half way? Chris. -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Jerome Tollet via lists.fd.io Sent: Tuesday, July 14, 2020 12:37 To: Steven Luong (sluong) ; Dave Barach (

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

The list has a good number of suggestions. In 802.1ax spec, they use the term aggregator and member link. So I am inclined to stick to aggregator/member unless someone finds that it is unacceptable. Steven From: Ed Warnicke Date: Tuesday, July 14, 2020 at 9:45 AM To: "Jerome Tollet (jtollet)"

[vpp-dev] VPP 20.05.1 tomorrow 15th July 2020

Hi all, As agreed on the VPP community call today, we will declare the current stable/2005 branch as v20.05.1 tomorrow (15th July) If you have any fixes that are already in master but not yet in stable/2005, that you want to get in there - please let me know before noon UTC. --a Your friendly

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

Steven, That sounds good to me. I tend to see this as "Get the good ideas for possible replacements out there so the folks doing the work have some inspiration for the choices". Please don't take the link as suggesting that list is the end all and be all of possible choices :) Ed On Tue, Jul 1

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

Hi Chris, I suspect it would be good to align on the new bond nomenclature coming from other projects. DPDK and Linux are probably starting points we should consider IMO. Jerome Le 14/07/2020 18:45, « t...@lists.fd.io au nom de Chris Luke » a écrit : It is subjective and contextualized.

Re: [vpp-dev] VPP 20.05.1 tomorrow 15th July 2020

Hi, Code for change id 27656 has been merged in master branch. This can be merged in stable/2005 Get Outlook for Android From: vpp-dev@lists.fd.io on behalf of Andrew Yourtchenko via lists.fd.io Sent: Tuesday, July 14, 2020 10:34:02 PM To

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

I believe the DPDK community converged on: master/slave lcore -> initial/worker lcore blacklist/whitelist -> blocklist/allowlist Full community discussion: https://mails.dpdk.org/archives/dev/2020-June/thread.html#169337 Jim -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Je

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

> On Jul 14, 2020, at 1:20 PM, St Leger, Jim wrote: > > I believe the DPDK community converged on: > master/slave lcore -> initial/worker lcore VPP is ok here I think with "main" and "worker". > blacklist/whitelist -> blocklist/allowlist That one feels a bit clunky to me. I wonder why they d

[vpp-dev] Firewall/NAT support for complex applications such as SIP, FTP etc..

Hi VPP team, I understand that VPP has firewall and NAT support. Some protocols are complex sessions, where they have control and data connections. Few examples are SIP and FTP. In these protocols, control connection service port is well known, but not the ports related to data connections. It

Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

I tend to prefer permitlist/denylist personally... but I may have configured one too many ACLs in my life... Ed On Tue, Jul 14, 2020 at 12:49 PM Christian Hopps wrote: > > > > On Jul 14, 2020, at 1:20 PM, St Leger, Jim > wrote: > > > > I believe the DPDK community converged on: > > master/slav

Re: [vpp-dev] VPP 20.05.1 tomorrow 15th July 2020

Hi Chinmaya, The custom practice is for the initiator of the commit to cherry-pick into the branches necessary, so the potential merge resolution is done by the SME. In this case it has cherry-picked cleanly - so if it passes the tests I will merge it into stable/2005 so as to have it in the dot-

[vpp-dev] FD.io - Decommission SonarQube Instance

*What:  *LF will decomission the FD.io SonarQue instance *When:*   2020-07-22 at 1700 UTC *Impact:  **sonar.fd.io and code quality reports and history will no longer be accessible* *Why:  *LF has migrated to SonarCloud. All FD.io project yaml files have been configured for SonarCloud jobs. *

[vpp-dev] FD.io - Decommission OpenGrok Instance

*What:  *LF will decomission the FD.io OpenGrok instance *When:*   2020-07-22 at 1700 UTC *Impact:  opengrok**.fd.io will no longer be accessible* *Why:  *After reviewing our inventory it doesn't appear OpenGrok is being used by the community. We'll be shutting the service down as a cost saving

Re: [vpp-dev] Firewall/NAT support for complex applications such as SIP, FTP etc..

Hi Srini, There is no "firewall" support in VPP, but rather a simple "stateful ACL", "stateless ACL", and "classifier" (the latter can operate on arbitrary bit-masked slice of the packet at fixed offsets). ACL plugin deliberately provides only a very simple concept of "stateful" ACL with very loo

Re: [vpp-dev] Firewall/NAT support for complex applications such as SIP, FTP etc..

Thanks Andrew. Good perspectives. I agree with everything you said. Middleboxes have lesser control due to end2end security protocols. You might be surprised, but there are few legacy end devices that still require some protocol ALGs 😊 in the middleboxes. In any case, I got the answer, that i

Re: [vpp-dev] VPP 20.05.1 tomorrow 15th July 2020

Hello Andrew, The following two fixes have been merged to the master branch, it would be good to have them in stable/2005 also: https://gerrit.fd.io/r/c/vpp/+/27280 (misc: ipfix-export unformat u16 collector_port fix) https://gerrit.fd.io/r/c/vpp/+/27281 (nat: fix regarding vm arg for vlib_time_