> > The implication being that while it might work, it would make > administration of the system onerous and unpredictable, considering we are > dealing with a ton of FreeBSD installations, and not just a single server. >
Adjusting a single tunable is 'onerous'? Ok. On Tue, May 9, 2023 at 9:00 AM Mark Tinka <mark@tinka.africa> wrote: > > > On 5/9/23 14:32, Tom Beecher wrote: > > > Except you didn't exactly "call out limitations". You simply said : > > IS-IS in Quagga and FRR are not yet ready for business, is what I would >> caution. >> > > The reality is that's not true. > > > And just a few weeks prior, I had given an update about this very issue, > as per attached. > > I figured if anyone needed more details (as I'd provided weeks prior), > they'd reach out, like Bryan did. > > > > - You have a specific environment ( FRR on FreeBSD ) that has an issue > with IS-IS. > - You identified the issue in Apr 2020 as related to the size of the PSNPs > being larger than the default BPF packet buffer size : > https://seclists.org/nanog/2020/Apr/238 > - Although a solution was provided ( > https://seclists.org/nanog/2020/Apr/240 ) , you made an affirmative > choice you didn't want to. ( https://seclists.org/nanog/2020/Apr/241 ) > > You didn't say "I don't want to adjust net.bpf.bufsize because it would > have negative impacts in my environment, so I need an option in FRR to > adjust the PSNP size." You said "I don't want to." > > > Ummh, not sure if you need help reading, but my exact words were: > > "Probably could - but I'd prefer solutions that don't mess with the > base > system, which ensures long term usability of FRR across future > upgrades." > > The implication being that while it might work, it would make > administration of the system onerous and unpredictable, considering we are > dealing with a ton of FreeBSD installations, and not just a single server. > > You, somehow, read my response is me being petulant; which is entirely > your right, of course. But I also won't let you make a false inference of > what my response actually was. > > > You are of course perfectly free to not make that change, and perfectly > free to gripe that FRR development has not done what you asked. But it's > pretty disingenuous to say that the software isn't "ready" strictly because > of issues in your use case. That doesn't really help anyone. > > > I made a statement, I was asked to explain, I did. There was historical > context, even though I can't expect you to file all member's postings to > memory. > > But if you want to let yourself get into your feelings, I can't help you > there. > > Mark. >
