>
> Customers have 0 complaints about IPv6. 0 Complaints since 2006.
>
Asserting that IPv6 shouldn't be a priority because 'nobody asks for it' is
specious. What if customers saw Cloudflare's "isbgpsafeyet" site and
demented you stop running BGP because it's "unsafe" ? Is that a valid
reason?
Cu
ay
purchases, and might blow up if we add the IPv6 DFZ."
The first one is all-too-common where I live, too. Fake it until you
make it is rife. Getting fibre into the ground - past as many homes as
possible - is the sole priority.
--
Tom
I would like to ask an earnest question here, because I work in an
environment where IPv6 has been deployed for more than a decade, and it's
just automatically part of things we do and have to solve for, so I will
openly admit my perspective can be warped. I am truly curious about what
the perceive
>
> Propaganda is in the eye of the beholder, and we’ve seen both sides of the
> political aisle sling this term in recent elections and legislative debates.
>
I agree with this as well.
History has shown us that the smallest sliver of 'interpretation' is likely
to eventually be twisted and explo
>
> Google sees over 40% of their users on ipv6,* with superior latency *
>
Uncle Geoff generally debunked this years ago.
https://www.youtube.com/watch?v=Lt-Xx2CmuQE&ab_channel=NANOG
On Thu, Mar 10, 2022 at 11:01 AM Ca By wrote:
>
>
> On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti wrote:
>
>> On
>
> It looked a lot lot an abandoned project. So unless something has
> changed in the last few years it's not looking good.
>
It's absolutely not abandoned. There have been vMX images up for download
for every mainline Junos revision since at least 18.2 that I can recall.
The documentation can b
cRPD is a pretty nifty product as well. Some interesting little tricks you
can do with that.
(Although I don't think they free trial that, those licenses are quite
reasonable as well. )
On Mon, Mar 14, 2022 at 2:34 PM Matt Harris wrote:
> Matt Harris
> | Infrastructure Lead
> 816‑256‑5446
> |
If you want to garner discussion or support for your draft RFC, it's
probably better to have that conversation via the appropriate IETF
channels.
On Mon, Mar 14, 2022 at 2:43 PM Abraham Y. Chen wrote:
> Hi, Fred:
>
> 0)Thank you for a set of references.
>
> 1)We cited only one IETF Draft
>
> Other arguments are political, and I do not presume to set international
> political policy. I only offer a technical opinion, not a political one.
>
Your technical opinion is what everyone is responding to.
Dropping support for any TLD in the root zone DB is a terrible idea,
period. Proposin
I would say if something passes the United States Senate in our current
political environment by unanimous consent (which this did) , I kinda feel
like there won't be a ton of issues with everybody figuring out how to line
themselves up appropriately.
On Tue, Mar 15, 2022 at 5:01 PM Eric Kuhnke w
>
> I’m all for giving up the time change, but the standard should probably
> still be UTC offset.
>
That's literally what the text of the bill does.
On Tue, Mar 15, 2022 at 5:08 PM Eric Tykwinski
wrote:
> What I don’t understand, is why change time, just change working hours.
> I’m all for giv
Operations | OTA Management LLC
>
> Office: 914-460-4039
> mh...@ox.com | www.ox.com
>
> ...
>
> -Original Message-
> From: NANOG On Behalf Of Jay R.
> Ashworth
&
No quibble about the discussion happening on a NOG list, not at all.
But frankly unless the proposal is even starting to move forward in the
IETF process such that a standards change is possible, it's just noise. ( I
don't predict that the draft being discussed ever gets that far anyways ;
it has
zation by an authoritative Internet
> figure. So, we imported it into our latest IETF draft update. Hopefully,
> this keyword will steer your opinion on EzIP.
>
> Regards,
>
>
> Abe (2022-03-16 10:49)
>
>
> ------
>
> NANOG Digest, Vo
>
> How *would* the timezone libraries handle "DST always on"? They would still
> have to flap, twice a year, right?
>
AFAIK, the way stuff works now is essentially "always get the standard
time, adjust it if DST is enabled and in effect."
On Wed, Mar 16, 2022 at 1:42 PM Jay R. Ashworth wrote:
“It seems all the market needed was IPv4 with bigger address space.
Instead of delivering it, some contraption has been created trying to solve
non-existant (or already fixed) problems.”
your argument against IPv6 is that they should have created a new version
of IPv4, but bigger?
So… IPv6?
On T
nor is it on their horizon.
>
>
>
>
>
> *Matthew Huff* | Director of Technical Operations | OTA Management LLC
>
>
>
> *Office: 914-460-4039*
>
> *mh...@ox.com | **www.ox.com <http://www.ox.com>*
>
>
> *..
ge imo, but we blowed it.
>
>
> -- Original message --
>
> From: Tom Beecher
> To: b...@uu3.net
> Cc: nanog@nanog.org
> Subject: Re: V6 still not supported
> Date: Thu, 17 Mar 2022 07:40:32 -0400
>
> ˙˙It seems all the market needed was IPv4 with bigger
gt; work.
> >
> >> Also, we need to please enterprises so we need largish RFC1918 space
> too.
> >
> > Why? Why does RFC-1918 space need to exist at all? Why not simply use
> transparent addressing and stop mutilating packet headers?
> >
> > However, if you re
>
> Primarily the ability to end-to-end authenticate end devices. The
> primary and largest glaring issue is that DHCPv6 from the client does
> not include the MAC address, it includes the (I believe) UUID.
>
DHCPv6 Option 79
https://datatracker.ietf.org/doc/html/rfc6939
>
>
On Sat, Mar 19, 20
>
> I wouldn’t assume that the small number of responses indicates a lack of
> interest. It’s possible that people haven’t commented because they’ve seen
> this topic play itself out over the years, and although they have opinions,
> they don’t feel compelled to post them there. (Interestingly en
You don't even have to use their equipment. My provider at home is Charter
/ Spectrum. I own my own cable modem / router ,they have no equipment in
my home. Their privacy policy is pretty standard.
Essentially :
- Anything they can see that I transmit they will collect.
- Anything they can see wh
The best practice with regards to as_path length is to have an edge filter
that dumps any prefix with a length longer than say 10. Depending on the
situation, might even be able to go smaller.
At a certain point, keeping that route around does nothing for you, just
shoot it and ride the 0/0 train.
>
> Even if you own your modem, the DOCSIS specs require that it be
> completely controlled by the MSO, right?
>
Pretty sure that's correct, yes.
On Fri, Mar 25, 2022 at 4:47 PM Michael Thomas wrote:
>
> On 3/24/22 12:53 PM, Tom Beecher wrote:
> > You don'
r some environments and use cases, but
I still am a firm believer that at a certain point, there is a length that
becomes straight 'really don't care'. I'd rather not discover a BGP
implementation problem or acid trip memory pointer party by accepting
announcements that are usel
>
> Have you ever considered that this may be in fact:
>
> */writing/* and */deploying/* the code that will allow the use of 240/4 the
> way you expect
>
While Mr. Chen may have considered that, he has repeatedly hand waved that
it's 'not that big a deal.', so I don't think he adequately grasps th
>
> It was quite frustrating since we did not have the background in
> networking software
You clearly still do not, if you sincerely believe that commenting out a
single function in every vendor software implementation is all that it
would take.
No need to respond ; I will be filtering all futu
worth
the effort it would take to make it happen. )
On Sat, Mar 26, 2022 at 9:42 PM John Gilmore wrote:
> Tom Beecher wrote:
> > > */writing/* and */deploying/* the code that will allow the use of
> 240/4 the
> > > way you expect
> >
> > While Mr. Chen may ha
>
> If the IETF has really been unable to achieve consensus on properly
> supporting the currently still dominant internet protocol, that is
> seriously problematic and a huge process failure.
>
That is not an accurate statement.
The IETF has achieved consensus on this topic. It's explained here
>
> . Less so a problem inherent to IPv4. A root cause fix would address
> Sony's hostile behavior.
>
Disagree, to a point.
The problem isn't technically with IPv4 itself, but with the lack of
availability of V4 addresses. This tends to force things like CGNAT, which
then compounds the problem wh
>
> I am an ARIN admin and tech POC for one of the affected ASNs/sets of
> prefixes across 2 OrgIDs. I looked back at the messages I've received
> that mention NONAUTH or Non-Authenticated. The only thing I've gotten is
> the message originally sent via ARIN-Announce that John forwarded, plus
> sim
>
> Cleaning it up is easy too. Publish an RPKI ROA for your space. We
> will automatically delete any route objects which disagree with an
> RPKI ROA. The routing security ecosystem should be doing that anyways.
>
"should" is a pretty tricky word to be using there.
On Mon, Apr 4, 2022 at 7:21 PM
I hear if they just moved to V6 and hosted email with Google, those emails
would just never arrive.
On Fri, Apr 8, 2022 at 12:40 PM Randy Bush wrote:
> > Does anyone else get email offers like the below?
>
> of course. i presume they signed the lrsa.
>
> randy
>
Marty knows a thing or two about the history and current state of affairs
in this world :)
Pretty much all of the major LECs have set the goal of full copper
retirement. But that is a long way away.
On Thu, Apr 14, 2022 at 8:58 PM Shane Ronan wrote:
> I think you'd be very surprised if you
>
> I always found the spades (?) of the 66 block to be convenient to clip a
> test set (with an angled bed of nails) onto. I've also used slip on
> jack more than a few times, especially for testing. E.g.
>
I agree that 66 blocks were always simpler for testing and troubleshooting,
but I always
Go virtual. x86 servers are still 5-8 weeks from our usual suppliers,
although some NICs are 12 weeks and DC Power Supplies are also
52-weeks/'no-idea'.
-- Tom
On Fri, Apr 22, 2022 at 6:21 AM Ryan Wilkins wrote:
> A company I work for designs a lot of our own hardware an
>
> The thing that is basically always true is that no commercial network is
> mixing cloud computing and eye ball users in the same blocks of IP
> addresses. I guess where this might be a grey area is Windows VMs on Azure
> where yes they are both eyeballs and potentially VPN users.
>
This is not
>
> If, for any reason, you want to opt out from us using your ASN for our
> experiments, you can do so in the following form before May 9:
>
> https://forms.gle/ZvZaodndPhCqMvR89
>
If I am interpreting this correctly that you are just going to yolo a bunch
of random ASNs to poison paths with, per
>
> When you the last time you asked the entire internet’s permission to
> announce routes ?
>
I am not suggesting that anyone ask for permission to announce routes.
I am suggesting they ask for permission to use ASNs that are not theirs in
the experiment, instead of forgiveness later for any op
>
> Short Disclaimer: I frequently use the PEERING testbed myself, so I'm
> genuinely interested in where and why people draw the boundary of what's
> fine and what's not.
>
Fine : Experimentation.
Not fine : Experimentation with number or ASN resources that are not yours
without prior permission
3am following four
hours of swearing, sweating and more swearing in a data centre.
Poutine uber alles.
--
Tom
>
> such as telegraf+influxdb+grafana, although that’s more resource intensive
> than the old school stuff that just works.
>
I'm also generally a fan of the older 'simple, just work' things , but
influxdb + grafana has absolutely grown on me over time.
On Thu, May 12, 2022 at 10:36 AM Rafael Pos
On 27/05/2022 14:32, Tom Krenn via NANOG wrote:
A little simple, but maybe Network Weathermap?
https://www.network-weathermap.com/
With some tuning of your variables, it's really easy to automate a very
useful topographical network diagram from practically any source of
data. You do ne
Thank you for calling out the HMC point. I think that alone is worth
retiring the platforms that were built around it.
The number of issues related the the HMC memory drivers were out of hand
early on, and lingered long past the growing pains phase.
I’m sure in the big picture, supply chain / man
Reach out to the folks at IP Architechs (https://iparchitechs.com/),
Readitech (https://engr.readitech.com/) or any of the good PE firms and
they can help.
-- Tom
On Tue, Jul 5, 2022 at 8:44 AM KCI Dave Logan via NANOG
wrote:
> Hi all. We operate a small regional ISP in Colorado, but no s
*CHI-NOG 10 – (Chicago Network Operators Group)*
*October 6th, 2022 in Chicago, IL*
The Chicago Network Operators Group (CHI-NOG) is a vendor neutral
organization. Our goal is to create a regional community of network
professionals by presenting the latest technology trends, enabling
collaboratio
>
> But in the mean time (and generally) this should really only be used in a
> dedicated VM. And the *primary* audience is my networks class--even though
> I shared with the broader networking community, in case others might find
> it useful or have feedback (thank you!).
>
It's a cardinal rule
> Believe being the operative word. Maybe you are right, maybe not,
> presenting it as factual truth is dishonest and potentially harmful.
>
> My general rule of thumb, satisfy legal, regulatory and customer
> contract requirements for infosec and other than that, largely ignore
> policies which ar
>
> Unfortunately it seems like policy that Verizon pushes any issues that
> aren't internal routing issues to an external party, but surely they have a
> responsibility to maintain their peering and routes to external services as
> well.
>
Baidu is behind CT. If CT is not passing on routes to 701
. If
> Verizon couldn't reach one of Google's edge servers, would it be Verizon or
> Google's responsibility to fix that if the issue were an intermediate peer
> failing to broadcase the correct route? I have the sneaking suspicion that
> Verizon might actually take some action
.
> From VZ engineer, I heard that no one is advertising it to AS701, so I
> assume it is not a case of VZ refusing to accept it (which is what I had
> initially assumed having been frustrated in the past with VZ on other
> matters + seeing all their BGP issues in the past few years).
>
>
> Also looking at routeviews, there's ample evidence that Verizon and China
> Telecom peer, so the question is, does China Telecom not advertise these
> routes to Verizon, or is Verizon rejecting them for some reason? I
> suspect only engineers at CT and VZ can answer that.
>
I took a quick loo
Well that shows my assertion was probably wrong.
Given the geopolitical situation between the US and China, along with
certain government orders, could likely infer this is intentional.
On Thu, Jul 21, 2022 at 12:33 PM Paul Rolland wrote:
> Hello,
>
> On Thu, 21 Jul 2022 12:20:37 -0400 (EDT)
>
>
> It wasn't a CPU analysis because switching ASICs != CPUs.
>
> I am aware of the x86 architecture, but know little of network ASICs,
> so I was deliberately trying to not apply my x86 knowledge here, in
> case it sent me down the wrong path. You made references towards
> typical CPU features;
>
is all that matters, regardless of what
label they want to apply to themselves.
On Mon, Aug 1, 2022 at 2:41 PM Rubens Kuhl wrote:
> On Mon, Aug 1, 2022 at 3:19 PM Geoff Huston wrote:
> >
> >
> >
> > > On 1 Aug 2022, at 11:10 am, Tom Paseka via NANOG
>
It always amazes me how an industry that has , since its inception, been
constantly solving new problems to make things work, always finds a way to
assume the next problem will be unsolvable.
On Tue, Aug 9, 2022 at 10:23 PM Christopher Wolff
wrote:
> Hi folks,
>
> Has anyone proposed that the ad
It's a pretty serious claim to say that cell providers were selectively not
delivering messages based on content.
Unless you have some more concrete evidence beyond "I sent a few texts" ,
this list is no place for such things, nor the insinuation of political
agendas.
On Wed, Aug 17, 2022 at 10:5
t; +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
> On Wed, Aug 17, 2022 at 10:46 AM Tom Beecher wrote:
> >
> > It's a pretty serious claim to say that cell providers were selectively
>
s, and T-Mo filters all goo.gl URLs,
> some might conclude that "T-Mobile filters links to right-leaning news
> outlets."
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH M-1C
> +1 256 824 5331
>
> Office of Information Technology
> The University o
>
>
> https://wjla.com/news/local/timeline-darren-thornton-sex-crime-case-fairfax-county-public-schools-fcps-virginia-what-we-know-arrest-charges-conviction-chesterfield-county-police-hiring-firing-corrections
>
> The outbound mail DID bounce. And the bounce message is what ended up in
> the sender
> Usually What shoud we do ? Should we filter it ?
>
As with many things, the answer depends on your situation.
If I was running an edge device with a limited FIB, perhaps I might drop
it to save memory. If I had beefier devices, perhaps I would just depref
it. Maybe it's a prefix/source ASN I h
Yeah,I meant RIB, not FIB. Should have finished coffee first. :)
On Fri, Aug 26, 2022 at 9:10 PM Lincoln Dale wrote:
> If I was running an edge device with a limited FIB, perhaps I might drop
>> it to save memory. If I had beefier devices, perhaps I would just depref
>> it.
>>
>
> Note that if s
>
> I would like to make an effort to debogon 240/4 at least, or have an
> authorized experiment to at least determine how fully bogon'd it is.
>
It would not be appropriate to 'debogon' 240/4 based on the currently
accepted definition, because it is space not allocated to an RIR. I know
that you
>
> Is there really such as thing as pure IPV6 only?
>
Yup.
On Thu, Sep 8, 2022 at 11:32 AM Paul Amaral via NANOG
wrote:
> Is there really such as thing as pure IPV6 only? I don’t think you will be
> able to run IPV6 for transport without the router locally knowing how to
> handle IPV4, at leas
William-
I am trying to follow your train of thought here. Are you stating that it
is somehow ARIN's responsibility to force a legal case to a
conclusion solely to settle the question of legacy allocation rights, a
problem which predates ARIN's existence? Or am I misunderstanding you?
On Fri, Sep
I would honestly love it if IANA was able to say "As of X date, all LEGACY
IPv4 allocations are transferred to the RIRs . Assignees will not change,
but will now need to comply with each RIRs policies."
Of course this will never happen, because it would just be a flood of
billable hours, lawsuits,
Adding NANOG Admins.
Also, for Bill and everyone else , s/admins/admin/ . NANOG has ONE staff
member who moderates the list, and that's one of many responsibilities that
person has. Just need to report it to the admins alias, and they will get
to it when they have time.
On Fri, Sep 16, 2022 at 5:
>
> I highly recommend that legacy holders who wish to ensure that their
> rights are respected transfer their registrations to RIPE-NCC, whether they
> have signed the LRSA or not.
>
For the uninitiated, this is the crux of the disagreements. (Before I
begin, this is not a personal shot at Owen o
care if
others don't get to do those things too."
On Mon, Sep 19, 2022 at 11:53 AM William Herrin wrote:
> On Mon, Sep 19, 2022 at 7:16 AM Tom Beecher wrote:
> > Allocations made before the RIR systems were created have no
> > contracts or covenants attached. Allocatio
>
> Honestly the root of a lot of the problems here is the bellheaded
> insistence of still using E.164 addresses in the first place. With SIP they
> are complete legacy and there is no reason that my "telephone number" can't
> be m...@mtcc.com.
>
You can do that all you want. You just don't get
foreseeable future.
On Tue, Oct 4, 2022 at 3:18 PM Michael Thomas wrote:
>
> On 10/4/22 11:58 AM, Tom Beecher wrote:
>
> Honestly the root of a lot of the problems here is the bellheaded
>> insistence of still using E.164 addresses in the first place. With SIP they
>>
>
> I thought that SCOTUS ruled years ago that telco users possess a First
> Amendment right to spoof Caller ID.
>
If you are referring to Facebook v. Duguid , that's not what the ruling
says at all.
On Wed, Oct 5, 2022 at 1:23 AM Matthew Black
wrote:
> I thought that SCOTUS ruled years ago t
Always a bunch of them out there. Sometimes accidental, sometimes from
folks who are trying to do something , just using ineffective methods to do
it.
On Tue, Oct 18, 2022 at 10:21 Sandoiu Mihai wrote:
> Hi
>
>
>
> We have witnessed a lot of prepending in the last days, we got a few
> internet
1. Prepending by itself isn’t bad. Prepending past the point that it is
effective in accomplishing anything is what you generally want to avoid.
Even then, it’s not nearly as big a deal as some make it out to be in most
cases.
2. De-aggregation has it’s uses and it’s place. Have a /20 , but announ
ts
was just as good. Maybe once I hit something that caused a performance
problem , but an email to that AS was all it took to fix ; they didn't
realize they were prepending that much and corrected it.
I have firsthand knowledge of some other networks that do similar things.
On Thu, Oct 20, 2022
>
> Are you taking the stance of "if you don't send us the prefix, then
> we don't accept the traffic"?
>
If you were one of my upstreams, and you implemented that, you would very
quickly no longer be one of my upstreams.
On Mon, Nov 7, 2022 at 2:22 PM Charles Rumford via NANOG
wrote:
> Hello
>
> 1) "... Africa ... They don’t really have a lot of alternatives. ...":
> Actually, there is, simple and in plain sight. Please have a look at the
> below IETF Draft:
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
For the benefit of anyone who may not un
>
> As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4 netblock."
>
Some friendly feedback. The phrase "all that needs to be done" , is
exceptionally reductive, and
t on this list.
On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen wrote:
> Dear Tom:
>
> 1) "... for various technical reasons , ...": Please give a couple
> examples, and be specific preferably using expressions that colleagues
> on this forum can understand.
>
&g
d them away or not
commented on them further.
On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen wrote:
> Dear Tom:
>
> 1) As requested, please be specific and speak only for yourself. So
> that we can carry on a professional dialog meaningfully.
>
> 2) Hint: I signed up to NANOG.or
This is basically exactly what has come out of the IETF for this and
similar ideas.
I doubt it will ever stop them from being put forth though.
On Mon, Nov 21, 2022 at 6:39 PM Eric Kuhnke wrote:
> Option A) Spend engineering time and equipment purchases to implement
> 240/4 as unicast globally.
>
> Serious consideration requires a serious proposal - I don’t think we’ve
> seen one yet.
>
I would posit that draft-schoen-intarea-unicast-240-03 (
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should
be considered a serious proposal, in so much as what is proposing is th
Mr. Chen-
I don't have any interest in continuing this discussion on this topic. Best
of luck to you.
On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen wrote:
> Dear Tom:
>
> Have not heard from you since the below MSG. Could you please let me
> know if you have seen it, so tha
r last MSG. The only thing that I could think of is
> that my last MSG provided the missing information that made the
> difference. I would appreciate very much if you could confirm.
>
> Regards,
>
>
> Abe (2022-12-02 22:35 EST)
>
>
>
> On 2022-12-01 16:34, Tom Beecher wro
Often lost in the 'debate' about V6 adoption is that for a 100% native IPv6
experience to work, there are multiple other components that have nothing
to do with the network that ALSO have to work correctly. Any issues with
these are likely going to cause fallback to v4.
It's very difficult to know
ads content, others tracking, market research, etc.
>
> Regards
> Jorge
>
> On Mon, Dec 5, 2022 at 11:09 AM Tom Beecher wrote:
>
>> Often lost in the 'debate' about V6 adoption is that for a 100% native
>> IPv6 experience to work, there are multiple other co
;
> On Mon, Dec 5, 2022 at 1:02 PM Tom Beecher wrote:
>
>> But IPv6Foo , ast least as far as I could tell by quickly looking at the
>> code, cannot tell you if an IPv6 connection WOULD have worked, but IPv4 is
>> where it ended up.
>>
>> With Happy Eyeballs,
Pushing thousands of lines via CLI/expect automation is def not a great
idea, no. Putting everything into a file, copying that to the device, and
loading from there is generally best regardless. The slowness you refer to
is almost certainly just because of how XR handles config application. If
I'm
>
> That's a take on it I really hadn't considered. I'm very aware that
> moving from a decade or two of legacy manual config to full data
> model/automation in a big bang is never going to work, but I'd been looking
> at what individual elements could be pulled out and automated with
> judicious
>
> Now, I would appreciate very much to see an example of how
> your eMail system handles the message threads. So that we can compare
> notes. Thanks,
>
Email *systems* don't do anything with threads. It's a construct of mail
clients. Even different mail clients do things differently, so as a ru
>
> Does AS15169 have a speed test? It would be nice to gauge the capacity to
> a particular network that's something laypeople could do.
>
15169 has enough capacity to external networks that a speed test from a
random 'layperson' is never going to give you any meaningful information.
On Wed, Dec
facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSd
/www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
st-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
> *From: *"Jared Mau
Disagree that it’s a line in the sand. It’s use the right tool for the job.
If a device is low FIB, it’s that way for a reason. There are plenty of
ways to massage that with policy and software, depending on capabilities ,
but at the end of the day, trying to sort 10 pounds of shit to store in a 5
ntelligent-computing-solutions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
l without the FIB
> routes, like in the olden days.
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions <http://www.ics-il.com/>
> > <https://www.facebook.com/ICSIL><
> https://plus.google.com/+IntelligentComputingSolution
linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>
/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
I can say with certainty at least one downlink location is not using Google
Fiber, as I am sitting about 1/2 mile from it , and have firsthand
knowledge of all glass in the ground around here.
On Wed, Jan 11, 2023 at 12:14 AM Dave Taht wrote:
> I maintain an email list for issues specific to sta
301 - 400 of 1187 matches
Mail list logo
