- dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 19 Jul '23

19 Jul '23

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1566378: (USE_AFTER_FREE) /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() ________________________________________________________________________________________________________ *** CID 1566378: (USE_AFTER_FREE) /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() 1683 /* first segment */ 1684 source->segments = new_seg; 1685 else if (prev_seg) 1686 prev_seg->next = new_seg; 1687 assegment_free(cur_seg); 1688 } >>> CID 1566378: (USE_AFTER_FREE) >>> Using freed pointer "cur_seg". 1689 prev_seg = cur_seg; 1690 cur_seg = next_seg; 1691 } 1692 1693 1694 aspath_str_update(source, false); /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() 1683 /* first segment */ 1684 source->segments = new_seg; 1685 else if (prev_seg) 1686 prev_seg->next = new_seg; 1687 assegment_free(cur_seg); 1688 } >>> CID 1566378: (USE_AFTER_FREE) >>> Using freed pointer "cur_seg". 1689 prev_seg = cur_seg; 1690 cur_seg = next_seg; 1691 } 1692 1693 1694 aspath_str_update(source, false); /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() 1683 /* first segment */ 1684 source->segments = new_seg; 1685 else if (prev_seg) 1686 prev_seg->next = new_seg; 1687 assegment_free(cur_seg); 1688 } >>> CID 1566378: (USE_AFTER_FREE) >>> Using freed pointer "cur_seg". 1689 prev_seg = cur_seg; 1690 cur_seg = next_seg; 1691 } 1692 1693 1694 aspath_str_update(source, false); /bgpd/bgp_aspath.c: 1689 in aspath_filter_exclude_acl() 1683 /* first segment */ 1684 source->segments = new_seg; 1685 else if (prev_seg) 1686 prev_seg->next = new_seg; 1687 assegment_free(cur_seg); 1688 } >>> CID 1566378: (USE_AFTER_FREE) >>> Using freed pointer "cur_seg". 1689 prev_seg = cur_seg; 1690 cur_seg = next_seg; 1691 } 1692 1693 1694 aspath_str_update(source, false); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 06 Jul '23

06 Jul '23

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1566150: Null pointer dereferences (NULL_RETURNS) /zebra/interface.c: 1527 in interface_vrf_change() ________________________________________________________________________________________________________ *** CID 1566150: Null pointer dereferences (NULL_RETURNS) /zebra/interface.c: 1527 in interface_vrf_change() 1521 vrf_id_t exist_id; 1522 1523 exist_id = zebra_vrf_lookup_by_table(tableid, ns_id); 1524 if (exist_id != VRF_DEFAULT) { 1525 vrf = vrf_lookup_by_id(exist_id); 1526 >>> CID 1566150: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "vrf", which is known to be "NULL". 1527 flog_err( 1528 EC_ZEBRA_VRF_MISCONFIGURED, 1529 "VRF %s id %u table id overlaps existing vrf %s(%d), misconfiguration exiting", 1530 name, ifindex, vrf->name, vrf->vrf_id); 1531 exit(-1); 1532 } ** CID 1566149: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1566149: Null pointer dereferences (NULL_RETURNS) /zebra/interface.c: 2288 in zebra_if_dplane_result() 2282 * that we need to handle( create/delete the 2283 * interface as needed ) 2284 */ 2285 if (dp_res == ZEBRA_DPLANE_REQUEST_QUEUED) 2286 zebra_if_dplane_ifp_handling(ctx); 2287 else >>> CID 1566149: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "ifp" when calling "zebra_if_update_ctx". 2288 zebra_if_update_ctx(ctx, ifp); 2289 break; 2290 2291 case DPLANE_OP_INTF_NETCONFIG: 2292 zebra_if_netconf_update_ctx(ctx, ifp, ifindex); 2293 break; ** CID 1566148: Control flow issues (DEADCODE) /zebra/interface.c: 1447 in zebra_if_netconf_update_ctx() ________________________________________________________________________________________________________ *** CID 1566148: Control flow issues (DEADCODE) /zebra/interface.c: 1447 in zebra_if_netconf_update_ctx() 1441 linkdown_set = &zrouter.default_linkdownv4; 1442 } else { 1443 mcast_set = &zrouter.default_mc_forwardingv6; 1444 linkdown_set = &zrouter.default_linkdownv6; 1445 } 1446 } else { >>> CID 1566148: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "NULL" inside this statement: "zif = (ifp ? ifp->info : NU...". 1447 zif = ifp ? ifp->info : NULL; 1448 if (!zif) { 1449 if (IS_ZEBRA_DEBUG_KERNEL) 1450 zlog_debug( 1451 "%s: if %s(%u) zebra info pointer is NULL", 1452 __func__, ifp ? ifp->name : "(null)", ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

FRR 8.5.2 Release
by Jafar Al-Gharaibeh 26 Jun '23

26 Jun '23

Dear FRR Community, We are pleased to announce FRR 8.5.2 bug fix release. For release notes please visit: https://frrouting.org/release/8.5.2/ https://github.com/FRRouting/frr/releases/tag/frr-8.5.2 Cheers, The FRR Development Team!

1 0

Re: [dev] Updating internal crypto implementation
by Acee Lindem 02 Jun '23

02 Jun '23

Given that I’m very new to the FRR dev community, I was hesitant to respond. However, I agree completely with Jafar. I’d add that OpenSSL is heavily tested by a large user community and CERTS are fixed very quickly. Additionally, if we ever implement BGP security features such as RPKI, we’ll use additional OpenSSL functionality. Thanks, Acee > On Jun 2, 2023, at 11:12, Jafar Al-Gharaibeh via dev <dev(a)lists.frrouting.org> wrote: > > > From: Jafar Al-Gharaibeh <jafar(a)atcorp.com <mailto:jafar@atcorp.com>> > Subject: Re: [dev] Updating internal crypto implementation > Date: June 2, 2023 at 11:12:40 EDT > To: "Ward, David - 0665 - MITLL" <david.ward(a)ll.mit.edu <mailto:david.ward@ll.mit.edu>> > Cc: "dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org>" <dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org>>, Donald Sharp <donaldsharp72(a)gmail.com <mailto:donaldsharp72@gmail.com>>, Christian Hopps <chopps(a)chopps.org <mailto:chopps@chopps.org>> > > > With OpenSSL 3.0+, the license is no longer an issue. Of course we still support a wide of older platforms where OpenSSL 3.0 isn't available out of the box. > > I don't see a good reason why one would write/maintain their own crypto functions when libraries are available. > > I can't think of a better option than OpenSSL when it comes to wide availability on systems we care about. > > --Jafar > > > > On 6/1/23 08:27, Ward, David - 0665 - MITLL wrote: >> I was actually intentionally vague, because I was first trying to elicit history, opinions, etc. about the current state of things. >> >> In particular: >> Am I correct in understanding the background behind OpenSSL and Zebra/Quagga/FRR? Is it believed that licensing issues which prevented redistribution in the past are resolved now? >> Is there a common expectation as to whether FRR is generally built with, or without, OpenSSL linkage today? (Distribution packaging varies: for example in Fedora this build flag is enabled, but in Debian it is disabled.) >> Are there strong feelings for or against having cryptographic algorithms embedded in the FRR source code? (Faster execution by using a specific implementation; larger security footprint to be concerned with monitoring within this project; easier to build and port FRR to other platforms by reducing the number of external dependencies; trickier to avoid potential function name collisions between FRR and system libraries; etc.) >> Are there strong feelings for or against the use of OpenSSL specifically in FRR today? (It’s a widely installed dependency of other software; it’s overkill for the very limited degree to which FRR uses it; it is likely to be ported to platforms that other libraries are not; it has a more involved API that has changed over time; etc.) >> >> (So far it seems like – all other things being equal – there would generally be a preference against embedding and maintaining these algorithms in FRR.) >> >> Thanks, >> >> David >> >> From: Donald Sharp <donaldsharp72(a)gmail.com> <mailto:donaldsharp72@gmail.com> >> Sent: Thursday, June 1, 2023 7:20 AM >> To: Christian Hopps <chopps(a)chopps.org> <mailto:chopps@chopps.org> >> Cc: Ward, David - 0665 - MITLL <david.ward(a)ll.mit.edu> <mailto:david.ward@ll.mit.edu>; dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> >> Subject: Re: [dev] Updating internal crypto implementation >> >> In theory, I am more than happy with having more security options in FRR, especially if some generic functions we are using can be taken out of FRR and the code maintenance can be taken care of by some other library. >> >> I guess where I have been hesitating to respond is the sentence `Can we update...`. I am not sure if I should read the sentence as either: >> >> a) David Ward is saying I will do the work to update this code >> b) The we implies that someone should just pick this up from the community and run with the idea. >> >> If (a) then I say go for it, David! For this work, though, I would want to see a plan of action for how this is going to be done in the code base. Mainly so that the 2-3 people within the FRR community who really really care about how this is done won't come back and say do it completely differently and your and our time is not wasted. >> >> if (b) then I say that's a great idea! Unfortunately due to how open source development is done, until some business has a use case for this expanded functionality, this idea is going to languish. >> >> Finally if you are going to do option (a), please feel free to privately send me email( or come talk to us on slack ) and we can get the ball rolling on helping you get the work done. >> >> thanks! >> >> donald >> >> >> >> On Thu, Jun 1, 2023 at 6:31 AM Christian Hopps <chopps(a)chopps.org <mailto:chopps@chopps.org>> wrote: >> >> Hi David, >> >> Add "Is there someone will to do the work and maintain the code?" to the non-library options. The answer to that q. very well could be "no" in which case the library is definitely the way to go. :) >> >> Thanks, >> Chris. >> >> "Ward, David - 0665 - MITLL" <david.ward(a)ll.mit.edu <mailto:david.ward@ll.mit.edu>> writes: >> >> > FRR has an "internal" implementation of the MD5 and SHA-256 algorithms, >> > including HMAC functions for both. [1] This code is under a BSD license, and >> > provides an alternative to linking FRR against OpenSSL, for which there were >> > historical (?) issues around GPL incompatibility. Several routing protocols use >> > one of these hash algorithms. >> > >> > ospf6d was extended last year to support the OSPFv3 Authentication Trailer (RFC 7166), which may use any of HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. [2] The choice of algorithm is limited unless FRR has been compiled with OpenSSL support. >> > >> > Can we update FRR's internal crypto implementation in order to overcome this limitation? For example: >> > * Gnulib provides a drop-in version of each of the algorithms mentioned above for inclusion in open-source projects, available under LGPL 2.1. >> > * FreeBSD has adapted Colin Percival's SHA-256 implementation to support the other SHA-2 algorithms (but without the HMAC functions - which would seem straightforward to adapt). >> > * Or should FRR rely on an external library for these functions instead? Should it allow the use of something other than OpenSSL, such as Libgcrypt? >> > >> > Thanks in advance, >> > >> > David >> > >> > >> > [1] The SHA-256 implementation was written by Colin Percival, originally for FreeBSD. His current version seems to be here: >> > https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c >> > >> > [2] ospf6d also supports the use of HMAC-MD5 here, despite this not being specified in RFC 7166. >> >> >> _______________________________________________ >> dev mailing list >> dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> >> 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

1 0

Re: [dev] Updating internal crypto implementation
by William Herrin 02 Jun '23

02 Jun '23

On Fri, Jun 2, 2023 at 8:12 AM Jafar Al-Gharaibeh via dev <dev(a)lists.frrouting.org> wrote: > I don't see a good reason why one would write/maintain their own crypto functions when libraries are available. It's notoriously tricky to write correct crypto implementations, particularly if crypto isn't your specialty. In my view, using a broadly tested implementation, particularly one that has been FIPS certified, should be the first, second and third choices. Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/

1 0

Re: [dev] Updating internal crypto implementation
by Ward, David - 0665 - MITLL 02 Jun '23

02 Jun '23

I was actually intentionally vague, because I was first trying to elicit history, opinions, etc. about the current state of things. In particular: * Am I correct in understanding the background behind OpenSSL and Zebra/Quagga/FRR? Is it believed that licensing issues which prevented redistribution in the past are resolved now? * Is there a common expectation as to whether FRR is generally built with, or without, OpenSSL linkage today? (Distribution packaging varies: for example in Fedora this build flag is enabled, but in Debian it is disabled.) * Are there strong feelings for or against having cryptographic algorithms embedded in the FRR source code? (Faster execution by using a specific implementation; larger security footprint to be concerned with monitoring within this project; easier to build and port FRR to other platforms by reducing the number of external dependencies; trickier to avoid potential function name collisions between FRR and system libraries; etc.) * Are there strong feelings for or against the use of OpenSSL specifically in FRR today? (It’s a widely installed dependency of other software; it’s overkill for the very limited degree to which FRR uses it; it is likely to be ported to platforms that other libraries are not; it has a more involved API that has changed over time; etc.) (So far it seems like – all other things being equal – there would generally be a preference against embedding and maintaining these algorithms in FRR.) Thanks, David From: Donald Sharp <donaldsharp72(a)gmail.com> Sent: Thursday, June 1, 2023 7:20 AM To: Christian Hopps <chopps(a)chopps.org> Cc: Ward, David - 0665 - MITLL <david.ward(a)ll.mit.edu>; dev(a)lists.frrouting.org Subject: Re: [dev] Updating internal crypto implementation In theory, I am more than happy with having more security options in FRR, especially if some generic functions we are using can be taken out of FRR and the code maintenance can be taken care of by some other library. I guess where I have been hesitating to respond is the sentence `Can we update...`. I am not sure if I should read the sentence as either: a) David Ward is saying I will do the work to update this code b) The we implies that someone should just pick this up from the community and run with the idea. If (a) then I say go for it, David! For this work, though, I would want to see a plan of action for how this is going to be done in the code base. Mainly so that the 2-3 people within the FRR community who really really care about how this is done won't come back and say do it completely differently and your and our time is not wasted. if (b) then I say that's a great idea! Unfortunately due to how open source development is done, until some business has a use case for this expanded functionality, this idea is going to languish. Finally if you are going to do option (a), please feel free to privately send me email( or come talk to us on slack ) and we can get the ball rolling on helping you get the work done. thanks! donald On Thu, Jun 1, 2023 at 6:31 AM Christian Hopps <chopps(a)chopps.org<mailto:chopps@chopps.org>> wrote: Hi David, Add "Is there someone will to do the work and maintain the code?" to the non-library options. The answer to that q. very well could be "no" in which case the library is definitely the way to go. :) Thanks, Chris. "Ward, David - 0665 - MITLL" <david.ward(a)ll.mit.edu<mailto:david.ward@ll.mit.edu>> writes: > FRR has an "internal" implementation of the MD5 and SHA-256 algorithms, > including HMAC functions for both. [1] This code is under a BSD license, and > provides an alternative to linking FRR against OpenSSL, for which there were > historical (?) issues around GPL incompatibility. Several routing protocols use > one of these hash algorithms. > > ospf6d was extended last year to support the OSPFv3 Authentication Trailer (RFC 7166), which may use any of HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. [2] The choice of algorithm is limited unless FRR has been compiled with OpenSSL support. > > Can we update FRR's internal crypto implementation in order to overcome this limitation? For example: > * Gnulib provides a drop-in version of each of the algorithms mentioned above for inclusion in open-source projects, available under LGPL 2.1. > * FreeBSD has adapted Colin Percival's SHA-256 implementation to support the other SHA-2 algorithms (but without the HMAC functions - which would seem straightforward to adapt). > * Or should FRR rely on an external library for these functions instead? Should it allow the use of something other than OpenSSL, such as Libgcrypt? > > Thanks in advance, > > David > > > [1] The SHA-256 implementation was written by Colin Percival, originally for FreeBSD. His current version seems to be here: > https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c > > [2] ospf6d also supports the use of HMAC-MD5 here, despite this not being specified in RFC 7166.

2 1

Updating internal crypto implementation
by Ward, David - 0665 - MITLL 01 Jun '23

01 Jun '23

FRR has an "internal" implementation of the MD5 and SHA-256 algorithms, including HMAC functions for both. [1] This code is under a BSD license, and provides an alternative to linking FRR against OpenSSL, for which there were historical (?) issues around GPL incompatibility. Several routing protocols use one of these hash algorithms. ospf6d was extended last year to support the OSPFv3 Authentication Trailer (RFC 7166), which may use any of HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. [2] The choice of algorithm is limited unless FRR has been compiled with OpenSSL support. Can we update FRR's internal crypto implementation in order to overcome this limitation? For example: * Gnulib provides a drop-in version of each of the algorithms mentioned above for inclusion in open-source projects, available under LGPL 2.1. * FreeBSD has adapted Colin Percival's SHA-256 implementation to support the other SHA-2 algorithms (but without the HMAC functions - which would seem straightforward to adapt). * Or should FRR rely on an external library for these functions instead? Should it allow the use of something other than OpenSSL, such as Libgcrypt? Thanks in advance, David [1] The SHA-256 implementation was written by Colin Percival, originally for FreeBSD. His current version seems to be here: https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c [2] ospf6d also supports the use of HMAC-MD5 here, despite this not being specified in RFC 7166.

3 2

Request: FRR Debian repository for Debian Bookworm
by Yeechan Lu 15 May '23

15 May '23

Hi there, I'm inquiring about packages of FRR Debian repository for the upcoming Debian Bookworm release scheduled next month [1]. I noticed that Bookworm may include FRR version 8.4.2-1; however, I am currently using version 8.5 from FRR Debian repository on Debian Bullseye already. I do not want to "downgrade". Could you please share details on their availability or any plans to support this version? Thanks for your great work on FRRouting. [1]: https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html Best regards, Yeechan Lu

2 1

Researchers Uncover New BGP Flaws in Popular Internet Routing Protocol Software
by Turritopsis Dohrnii Teo En Ming 10 May '23

10 May '23

Subject: Researchers Uncover New BGP Flaws in Popular Internet Routing Protocol Software Good day from Singapore, I have just come across this article. Thought of sharing it. Article: Researchers Uncover New BGP Flaws in Popular Internet Routing Protocol Software Link: https://thehackernews.com/2023/05/researchers-uncover-new-bgp-flaws-in.html Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com GIMP also stands for Government-Induced Medical Problems.

1 0

Re: [sonic-dev] [sonic-wg-routing] A reminder for 5/4 SONiC Routing WG kick off meeting
by Eddie Ruan 04 May '23

04 May '23

Thanks Lucy for bringing this issue up. I will ask our in house BGP folks to evaluate these three issues. In general, I would expect this is the issue for SONiC deployment as we use FRR BGP. Thanks Eddie ------------------------------------------------------------------ From:Lucy Hyde <lhyde(a)linuxfoundation.org> Sent At:2023 May 3 (Wed.) 19:21 To:sonic-wg-routing@lists.sonicfoundation.dev <sonic-wg-routing(a)lists.sonicfoundation.dev>; sonic-dev <sonic-dev(a)lists.sonicfoundation.dev>; Praveen Bhagwatula (pbhagwat) <pbhagwat(a)cisco.com>; Syed Hasan Raza Naqvi <syed.naqvi(a)broadcom.com>; Rita Hui <Rita.Hui(a)microsoft.com>; dev <dev(a)lists.frrouting.org> Cc:Yanzhao Zhang <yanzhaoz(a)microsoft.com>; Lihua Yuan <Lihua.Yuan(a)microsoft.com> Subject:Re: [sonic-dev] [sonic-wg-routing] A reminder for 5/4 SONiC Routing WG kick off meeting Hello SONiC Routing Working Group, I’m not sure if this is the appropriate place to ask this question and will also bring it up to the TSC- but I saw the note about using FRR in SONiC below and this article was flagged to me for investigation this morning: https://thehackernews.com/2023/05/researchers-uncover-new-bgp-flaws-in.html… <https://thehackernews.com/2023/05/researchers-uncover-new-bgp-flaws-in.html… > It discusses three vulnerabilities in FRRouting, and specifically mentions Cumulus, DENT, and SONiC. Please let me know if this is already being worked (so I can let Arpit know) and if not, if I can provide any assistance with regard to security scanning and audit and how you would like to proceed. Best, Lucy Lucy Hyde Program Manager | LF Projects in AI & Networking The Linux Foundation From: sonic-wg-routing(a)lists.sonicfoundation.dev <sonic-wg-routing(a)lists.sonicfoundation.dev> on behalf of Eddie Ruan via lists.sonicfoundation.dev <eddie.ruan=alibaba-inc.com(a)lists.sonicfoundation.dev> Date: Wednesday, May 3, 2023 at 12:15 PM To: sonic-wg-routing <sonic-wg-routing(a)lists.sonicfoundation.dev>, sonic-dev <sonic-dev(a)lists.sonicfoundation.dev>, Praveen Bhagwatula (pbhagwat) <pbhagwat(a)cisco.com>, Syed Hasan Raza Naqvi <syed.naqvi(a)broadcom.com>, Rita Hui <Rita.Hui(a)microsoft.com>, dev <dev(a)lists.frrouting.org> Cc: Yanzhao Zhang <yanzhaoz(a)microsoft.com>, Lihua Yuan <Lihua.Yuan(a)microsoft.com> Subject: [sonic-wg-routing] A reminder for 5/4 SONiC Routing WG kick off meeting Hi, Just a friendly reminder that we will have routing WG kick off meeting on 5/4 5:30-6:30pm PST (5/5 8:30-9:30 am China time). The zoom info could be found below. You could subscribe this WG via https://lists.sonicfoundation.dev/g/sonic-wg-routing <https://lists.sonicfoundation.dev/g/sonic-wg-routing > * Subscribe: sonic-wg-routing+subscribe(a)lists.sonicfoundation.dev <mailto:sonic-wg-routing+subscribe@lists.sonicfoundation.dev > I also include FRR email alias as well, since we use FRR as routing stack in SONiC and there are some enhancements needed from both FRR and SONiC to fully support routing features. Thanks Praveen, Hasan, Rita, Eddie Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://zoom.us/meeting/tJEvdOCpqjsoG9dYQnhKle_6lwCLbPogZgPq/ics?icsToken=9… <https://zoom.us/meeting/tJEvdOCpqjsoG9dYQnhKle_6lwCLbPogZgPq/ics?icsToken=9… > Join Zoom Meeting https://zoom.us/j/95239140213 <https://zoom.us/j/95239140213 > Meeting ID: 952 3914 0213 One tap mobile +13126266799,,95239140213# US (Chicago) +16465588656,,95239140213# US (New York) Dial by your location +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 646 931 3860 US +1 301 715 8592 US (Washington DC) +1 305 224 1968 US +1 309 205 3325 US +1 360 209 5623 US +1 386 347 5053 US +1 507 473 4847 US +1 564 217 2000 US +1 669 444 9171 US +1 669 900 6833 US (San Jose) +1 689 278 1000 US +1 719 359 4580 US +1 253 205 0468 US +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 204 272 7920 Canada +1 438 809 7799 Canada +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +1 778 907 2071 Canada +1 780 666 0144 Canada 855 703 8985 Canada Toll-free Meeting ID: 952 3914 0213 Find your local number: https://zoom.us/u/aewVD44sd4 <https://zoom.us/u/aewVD44sd4 > _._,_._,_ Links: You receive all messages sent to this group. View/Reply Online (#278) <https://lists.sonicfoundation.dev/g/sonic-dev/message/278 > | Reply To Sender <mailto:lhyde@linuxfoundation.org?subject=Private:%20Re:%20Re%3A%20%5Bsonic-dev%5D%20%5Bsonic-wg-routing%5D%20A%20reminder%20for%205%2F4%20SONiC%20Routing%20WG%20kick%20off%20meeting > | Reply To Group <mailto:sonic-dev@lists.sonicfoundation.dev?subject=Re:%20Re%3A%20%5Bsonic-dev%5D%20%5Bsonic-wg-routing%5D%20A%20reminder%20for%205%2F4%20SONiC%20Routing%20WG%20kick%20off%20meeting > | Mute This Topic <https://lists.sonicfoundation.dev/mt/98676540/7341548 > | New Topic <https://lists.sonicfoundation.dev/g/sonic-dev/post > Your Subscription <https://lists.sonicfoundation.dev/g/sonic-dev/editsub/7341548 > | Contact Group Owner <mailto:sonic-dev+owner@lists.sonicfoundation.dev > | Unsubscribe <https://lists.sonicfoundation.dev/g/sonic-dev/leave/11873633/7341548/944543… > [eddie.ruan(a)alibaba-inc.com] _._,_._,_

1 0