Re: BGP Engines with support to "RTFilter address-family"
> RFC4364 ... I believe - Arccus has implemented it (Keyur to confirm) i am not keyur and do not play one on the net, but ...
Re: 2023 State of Network Automation Survey
On Mon, Feb 27, 2023 at 2:30 PM Tom Beecher wrote: > Having the opt out is nice, but if I am being completely honest, it gives > me pause as to what the intent of this survey is in the first place. > > I perhaps may be hyper cynical, but those feel like a straight line > towards the standard salesperson line of "look at what you are spending now > on FOO , you could save X if you used BAR". > Fair play, Tom. All I can say is that after 20 years of working on, in, and around the Internet, I'm sure as hell not going to ruin my reputation now. The intent of the survey is exactly as I stated: To report network automation trends back to the community. And whether we engineers like it or not, one of the best ways to measure trends is in the relative amount of money organizations spend on them... HTH, ~Chris > On Mon, Feb 27, 2023 at 4:12 PM Chris Grundemann > wrote: > >> On Mon, Feb 27, 2023 at 12:15 PM Tom Beecher wrote: >> >>> >>> I was also off put by some of the financial questions in there. >>> >> >> The financial questions (2 of them) both allow opt-out if that is a >> sticking point. They are also both as vague as possible (large ranges, not >> exact figures) while still providing something to baseline against. >> >> >>
Re: 2023 State of Network Automation Survey
On Mon, Feb 27, 2023 at 11:57 AM Denis Fondras wrote: > Le Mon, Feb 27, 2023 at 11:16:13AM -0700, Chris Grundemann a écrit : > > Update: The survey has received almost 4 dozen responses already! > > > > Of course, for the most meaningful results possible, I'd like to see that > > about 10x higher. > > > > Don't expect too much when you need a Google account to answer a survey :) > For better or worse, some form of SPAM protection is needed for publically available surveys. A free account seems like a low bar - but I acknowledge that it is a bar. If you would like a private survey to complete without requiring a Google account, please let me know directly and I will find a way to make that happen. This is an open invite to all who share Denis' concern. > > > If you help run a network and have not yet responded, please consider > doing > > so - it really should only take a few minutes, and we'll all be better > off > > having the additional data point: > > > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > > > > > Thanks so much! > > ~Chris > > >
Re: 2023 State of Network Automation Survey
Having the opt out is nice, but if I am being completely honest, it gives me pause as to what the intent of this survey is in the first place. I perhaps may be hyper cynical, but those feel like a straight line towards the standard salesperson line of "look at what you are spending now on FOO , you could save X if you used BAR". On Mon, Feb 27, 2023 at 4:12 PM Chris Grundemann wrote: > On Mon, Feb 27, 2023 at 12:15 PM Tom Beecher wrote: > >> >> I was also off put by some of the financial questions in there. >> > > The financial questions (2 of them) both allow opt-out if that is a > sticking point. They are also both as vague as possible (large ranges, not > exact figures) while still providing something to baseline against. > > >
Re: BGP Engines with support to "RTFilter address-family"
FRR hasn’t implemented RFC4364 (nor planning to my knowledge (unless someone comes and codes it ;-)) I believe - Arccus has implemented it (Keyur to confirm). Cheers, Jeff > On Feb 26, 2023, at 22:58, Paul Rolland wrote: > > Hello, > >> On Sun, 26 Feb 2023 17:46:42 -0300 >> Douglas Fischer wrote: >> >> But I'm looking for an open-source engine that supports it. >> >> The official FRR documentation does not mention anything about RFC 4364, >> or RTFilter address family. >> So, I think FRR does not support RTFilter Constrained Route Distribution. >> >> Do any of the colleagues have any suggestions on this? > > ExaBGP ? > > https://github.com/Exa-Networks/exabgp/wiki/RFC-Information > > Best, > Paul > > -- > Paul RollandE-Mail : rol(at)witbe.net > CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 > 18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99 > F-92000 NanterreRIPE : PR12-RIPE > > Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un > navigateur "Some people dream of success... while others wake up and work > hard at it" > > "I worry about my child and the Internet all the time, even though she's > too young to have logged on yet. Here's what I worry about. I worry that 10 > or 15 years from now, she will come to me and say 'Daddy, where were you > when they took freedom of the press away from the Internet?'" > --Mike Godwin, Electronic Frontier Foundation
Re: 2023 State of Network Automation Survey
On Mon, Feb 27, 2023 at 12:15 PM Tom Beecher wrote: > > I was also off put by some of the financial questions in there. > The financial questions (2 of them) both allow opt-out if that is a sticking point. They are also both as vague as possible (large ranges, not exact figures) while still providing something to baseline against.
Re: Reverse Traceroute
On 2/27/23 1:13 AM, Rolf Winter wrote: But feedback from the operational community on this would be valuable. Our reverse traceroute currently restricts the server to trace back to the issuing client. We did this for security reasons. I understand the motivation for your team's caution / security posture. The question was "why should anybody on the internet be able to do a traceroute from my server to a destination of choice?". How many times have we been out and about in our daily lives and received a text / phone call that prompted us to initiate diagnostic between two locations other than where we were at or where our traffic appeared to originate from? Lifting this restriction would allow a functionality similar to "https://downforeveryoneorjustme.com/;. But, somebody might use your server for this. How do people feel about this? Restrict the reverse traceroute operation to be done back to the source or allow it more freely to go anywhere? I'm already trusting the RIPE team and their security measures for the Atlas probe that's in my network. I'm okay continuing to rely on them to monitor and react to this if it becomes a problem. Perhaps the RIPE team could make a test to an arbitrary destination (considerably ~> 10 x) more expensive (in credits) than to the destination that you're initiating from. Just my 2¢. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
Re: 2023 State of Network Automation Survey
> > Don't expect too much when you need a Google account to answer a survey :) > I was also off put by some of the financial questions in there. On Mon, Feb 27, 2023 at 1:57 PM Denis Fondras wrote: > Le Mon, Feb 27, 2023 at 11:16:13AM -0700, Chris Grundemann a écrit : > > Update: The survey has received almost 4 dozen responses already! > > > > Of course, for the most meaningful results possible, I'd like to see that > > about 10x higher. > > > > Don't expect too much when you need a Google account to answer a survey :) > > > If you help run a network and have not yet responded, please consider > doing > > so - it really should only take a few minutes, and we'll all be better > off > > having the additional data point: > > > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > > > > > Thanks so much! > > ~Chris > > > > > > > > On Mon, Feb 20, 2023 at 6:06 PM Chris Grundemann > > wrote: > > > > > Hail NANOGers! > > > > > > For those of you who were unable to attend my lightning talk las > Wednesday > > > (link below) I would like to ask that you all complete the 2023 State > of > > > Network Automation Survey: > > > > > > > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > > > > > I did my best to make it as short as possible while collecting enough > data > > > to be useful. I will share the analysed and anonymized results with all > > > respondents, as well as (assuming the talk is accepted) at the next > NANOG > > > meeting. > > > > > > Feel free to send any questions directly, although I hope the survey is > > > self-explanatory. > > > > > > For a bit more context, the lightning talk can be viewed here: > > > https://youtu.be/p7rlhkmlDog > > > > > > Thanks in advance for your participation! > > > > > > Cheers, > > > ~Chris > > > > > > > > > -- > > > @ChrisGrundemann > > > http://chrisgrundemann.com > > > > > > > > > -- > > @ChrisGrundemann > > http://chrisgrundemann.com >
Re: 2023 State of Network Automation Survey
Le Mon, Feb 27, 2023 at 11:16:13AM -0700, Chris Grundemann a écrit : > Update: The survey has received almost 4 dozen responses already! > > Of course, for the most meaningful results possible, I'd like to see that > about 10x higher. > Don't expect too much when you need a Google account to answer a survey :) > If you help run a network and have not yet responded, please consider doing > so - it really should only take a few minutes, and we'll all be better off > having the additional data point: > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > > Thanks so much! > ~Chris > > > > On Mon, Feb 20, 2023 at 6:06 PM Chris Grundemann > wrote: > > > Hail NANOGers! > > > > For those of you who were unable to attend my lightning talk las Wednesday > > (link below) I would like to ask that you all complete the 2023 State of > > Network Automation Survey: > > > > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > > > I did my best to make it as short as possible while collecting enough data > > to be useful. I will share the analysed and anonymized results with all > > respondents, as well as (assuming the talk is accepted) at the next NANOG > > meeting. > > > > Feel free to send any questions directly, although I hope the survey is > > self-explanatory. > > > > For a bit more context, the lightning talk can be viewed here: > > https://youtu.be/p7rlhkmlDog > > > > Thanks in advance for your participation! > > > > Cheers, > > ~Chris > > > > > > -- > > @ChrisGrundemann > > http://chrisgrundemann.com > > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com
Re: 2023 State of Network Automation Survey
Update: The survey has received almost 4 dozen responses already! Of course, for the most meaningful results possible, I'd like to see that about 10x higher. If you help run a network and have not yet responded, please consider doing so - it really should only take a few minutes, and we'll all be better off having the additional data point: https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link Thanks so much! ~Chris On Mon, Feb 20, 2023 at 6:06 PM Chris Grundemann wrote: > Hail NANOGers! > > For those of you who were unable to attend my lightning talk las Wednesday > (link below) I would like to ask that you all complete the 2023 State of > Network Automation Survey: > > https://docs.google.com/forms/d/e/1FAIpQLSc5J_i2rkcpgkvI83Vj3DRVsau5jZ1u99M7p_ecWOgnW_9XHg/viewform?usp=sf_link > > I did my best to make it as short as possible while collecting enough data > to be useful. I will share the analysed and anonymized results with all > respondents, as well as (assuming the talk is accepted) at the next NANOG > meeting. > > Feel free to send any questions directly, although I hope the survey is > self-explanatory. > > For a bit more context, the lightning talk can be viewed here: > https://youtu.be/p7rlhkmlDog > > Thanks in advance for your participation! > > Cheers, > ~Chris > > > -- > @ChrisGrundemann > http://chrisgrundemann.com > -- @ChrisGrundemann http://chrisgrundemann.com
Re: Upstream bandwidth usage
I dug out this old thread again... https://www.broadband.io/c/get-broadband-grant-alerts-news/the-brothers-wisp-podcast What is the request/grant latency in various gpons? DOCSIS-LL has it below 2ms, I think. On Sun, Jun 12, 2022 at 12:00 AM Mark Tinka wrote: > > > > On 6/11/22 22:20, Karsten Thomann via NANOG wrote: > > > > > Does anyone know the Asian market where they are using E-PON? > > After my very short search it seems they provide best effort up to 1G > > without > > any real plans... > > When I was in Malaysia years back, we did use ZTE for some EPON > services. But we retired those and moved to GPON. > > Mark. -- A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/ Dave Täht CEO, TekLibre, LLC
Re: Reverse Traceroute
On Mon, 27 Feb 2023 at 10:16, Rolf Winter wrote: > "https://downforeveryoneorjustme.com/;. But, somebody might use your > server for this. How do people feel about this? Restrict the reverse > traceroute operation to be done back to the source or allow it more > freely to go anywhere? What are the pros and cons of this? Let's call it destination TLV. If I am someone who wants to do volumetric attack, I won't set any destination TLV, because without destination TLV and by spoofing my source, I get more leverage. If my source and destination TLV differ, then I have less leverage. So in this sense, it adds no security implications, but adds a massive amount of diagnostic power, as one very common request is to ask traceroute between nodes you have no access to. What it would allow is port knocking the ports used through proxy, if this matters or not might be debatable. Perhaps the standard should consider some abilities to be default on, and others default off, and let the operator decide if they want to turn some default off abilities on, such as honoring destination TLV. -- ++ytti
Re: Reverse Traceroute
Am 27.02.23 um 01:35 schrieb Grant Taylor via NANOG: On 2/25/23 3:09 AM, Tore Anderson wrote: I suggest you get in touch with the fine folks at NLNOG RING and ask it they would be interested in setting this up on the 600+ RING nodes all over the world. See https://ring.nlnog.net/. Similarly you might reach out to RIPE and inquire if they are interested in adding this functionality to their Atlas Probes et al. RIPE Atlas is a bit "different" in that you need credits to trigger something on Atlas. And Atlas already implements traceroute, incl. Paris Traceroute. That means, in fact (if you have credits) you can already reverse traceroute from an Atlas Probe to yourself (and other places on the internet). But, you are raising in interesting point, which we have thought about but dismissed. But feedback from the operational community on this would be valuable. Our reverse traceroute currently restricts the server to trace back to the issuing client. We did this for security reasons. The question was "why should anybody on the internet be able to do a traceroute from my server to a destination of choice?". Lifting this restriction would allow a functionality similar to "https://downforeveryoneorjustme.com/;. But, somebody might use your server for this. How do people feel about this? Restrict the reverse traceroute operation to be done back to the source or allow it more freely to go anywhere? Best, Rolf smime.p7s Description: S/MIME Cryptographic Signature
