RE: SDN Internet Router (sir)

[Chris Wright]

I love that we can't even get a full week into the new year without beating the 
"let's overhaul BGP" drum. Some things never change. <3

Chris


-Original Message-
From: NANOG  On 
Behalf Of Joe Maimon
Sent: Thursday, January 5, 2023 5:51 PM
To: Mel Beckman ; Mike Hammett 
Cc: NANOG 
Subject: Re: SDN Internet Router (sir)

And here is another interesting approach Ive left open in my browser window for 
who knows how long

https://inog.net/files/iNOG14v_oliver_sourcerouting.pdf

The problem with BGP is that local actors can exact global costs trivially by 
consuming as many routing slots as they can get away with, add together BGP 
path decisions and Most Specific traffic-engineering is the goto knob. 
Sometimes you just want to say this is the route, do not accept any more 
specifics, unless this route is no longer the route. But you want that done 
automatically and correctly, reliably.

This is also why all the multi-homing approaches that do not involve global 
routing havent really taken off in any way to blunt table growth. 
And likely wont.

See the aggregation factor in the routing report for how bad this is.

There have been lots of BGP protocol and feature updates, but unless your going 
to uniformly run new systems and enterprise systems that support all of them, 
its hard to decide to build your entire routing strategy around them.

That BGP unlike EIGRP never tried to tie together performance indicators with 
routing metrics feature or misdesign, you could debate that but it was always 
intentional. And opex has pretty much fallen down on the side of against 
IGP->BGP redistribution of prefixes, let alone performance metrics.

That eBGP prefix has no good reliable way of indicating that an advertised 
route sucks so bad that you should never attempt to use it unless as last 
resort, thats why we have AS-paths wrapping screen lines.

"finish IPv6 migration"? Letting IPv6 migration state factor as decision input 
on anything not directly related to IPv6 migration was never logical, just 
naively optimistic, and should be stamped out wherever encountered. If its 
good, use it now and Ipv6 will adopt it as well. If it isnt, why wait to find 
out?

Joe

Mel Beckman wrote:
> Mike,
>
> Thanks for that useful example. On a side note, Netflix is a thorn in 
> all our sides :) You could put a localpref filter route to override 
> the default for Netflix prefixes, but this impacts resilience. Since 
> you peer with Netflix, I suspect we probably agree that Netflix’s 
> ideas on traffic engineering are pretty one sided.
>
> I think it’s safe to say that BGP, which has scaled amazingly well, 
> didn’t anticipate some of the big gorilla content systems. I don’t 
> really see, though, how injecting FIB entries helps more than other 
> methods. And as others have pointed out, the risk of creating routing 
> loops is significant.
>
> Perhaps it is time to migrate to a new version of BGP.  Projects like 
> MBGP and FP-7‘s 4WARD are working on new follow-on routing models, but 
> nothing is on the immediate horizon. I think we all thought we should 
> finish IPv6 migration first :)
>
> -mel via cell
>
>> On Jan 5, 2023, at 1:11 PM, Mike Hammett  wrote:
>>
>> 
>> I hesitated to get too specific in examples because someone is going 
>> to drag the conversation into the weeds.
>>
>> Let's take the the Dallas - New Orleans - Atlanta example where I 
>> have a connection from New Orleans to Dallas and a connection from 
>> New Orleans to Atlanta.
>>
>> Let's say I peer with Netflix in both markets. Netflix chooses to 
>> serve me out of Atlanta, for whatever reason. Say my default route 
>> sends my traffic to Dallas. That's not where Netflix wanted it, so 
>> now I have to go from Dallas to Atlanta, whether that's my circuit or 
>> across the public Internet. Potentially, it's on MPLS and it rides 
>> back through the New Orleans router to get back to Atlanta. That's a 
>> long trip when I already had a better path, the less-than-full-fib 
>> router just didn't know about it. Given that Netflix is a sizable 
>> amount of traffic in an eyeball ISP, that's a lot of traffic to be 
>> going the wrong way. If the website for Viktor's Arctic Plunge in 
>> Siberia was hosted in Atlanta, I wouldn't give two craps that the 
>> traffic went the wrong way because A), I'll probably never go there 
>> and B) when someone does, it won't be meaningfully enough traffic to 
>> accommodate.
>>
>> Someone's going to tell me to put a full-table router in New Orleans. 
>> Maybe I should. Okay, so maybe I have a POP in Ashford, Alabama. It 
>> has transport to New Orleans and Atlanta. There aren't enough grains 
>> of sugar in Ashford, Alabama to justify a current-generation, full 
>> table router. Now I'm even closer to Atlanta, but default may point 
>> to New Orleans.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 

RE: juniper.net down?

[Chris Wright]

Works for me on the east coast.

Chris

From: NANOG  On 
Behalf Of aar...@gvtc.com
Sent: Tuesday, October 18, 2022 2:13 PM
To: nanog@nanog.org
Subject: juniper.net down?

juniper.net down?



Aaron
aar...@gvtc.com

RE: ServiceNow

[Chris Wright]

I guess now's a good time to recommend this handy site for when you'd like a 
view from the outside:

https://ping.pe

No issues at this time reaching that address from pretty much anywhere.

-

Chris


From: NANOG  On 
Behalf Of Mann, Jason via NANOG
Sent: Wednesday, August 31, 2022 1:59 AM
To: nanog@nanog.org
Subject: ServiceNow

Anyone else having issues getting to service now? We use it for ticketing: 
montana.servicenowservices.com [149.96.184.230]. Im not seeing it in our 
internet routers nor on a couple of looking glass servers.

RE: BGP Visualization with Software Galaxies

[Chris Wright]

BGPLay works pretty well.

https://stat.ripe.net/about/


From: NANOG  On 
Behalf Of Jacques Latour
Sent: Tuesday, August 23, 2022 2:17 PM
To: NANOG 
Subject: BGP Visualization with Software Galaxies

I was looking for a functional version of a BGP visualisation tool like the one 
at NTT http://as2914.net/, it does not seem to work or be updated.

Is there a public facing functional tool somewhere? I like this tool to show 
the complexity of our internet from a spaceship point of view COOL 


  *   
https://github.com/anvaka/pm/tree/master/about#software-galaxies-documentation

Thanks!

Jacques

RE: IPv6 internet broken, cogent/telia/hurricane not peering

[Chris Wright]

The reply must've been stuck in Cogent's network for the past 13 years. 

Chris

-Original Message-
From: NANOG  On 
Behalf Of Chris Adams
Sent: Thursday, August 11, 2022 10:17 AM
To: nanog@nanog.org
Subject: Re: IPv6 internet broken, cogent/telia/hurricane not peering

Once upon a time, Niels Bakker  said:
> * volki...@gmail.com (VOLKAN KIRIK) [Thu 11 Aug 2022, 15:52 CEST]:
> >hello
> 
> You're replying to a thread from 2009. Please advise.

Maybe they're a Cogent sales rep that, when trying snipe a customer's customer, 
got push-back on "can I get to Google and HE on IPv6 on your circuit?".
--
Chris Adams 

RE: IoT - The end of the internet

[Chris Wright]

That’s just humans in general, and it certainly isn’t limited to our outlook on 
the future of the internet. Big advancements will always take us by surprise 
because our lizard brains have a hard time comprehending exponential growth. 
Someone please stop me here before I get on my Battery-EV soapbox. :D

Chris

From: NANOG  On 
Behalf Of Tom Beecher
Sent: Wednesday, August 10, 2022 9:25 AM
To: Christopher Wolff 
Cc: NANOG 
Subject: Re: IoT - The end of the internet

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 
mailto:ch...@vergeinternet.com>> wrote:
Hi folks,

Has anyone proposed that the adoption of billions of IoT devices will 
ultimately ‘break’ the Internet?

It’s not a rhetorical question I promise, just looking for a journal or other 
scholarly article that implies that the Internet is doomed.

RE: Question re. operator tools - somewhere betwixt fast failover and TE

[Chris Wright]

I’m not entirely certain these are problems that operators necessarily concern 
themselves with. Datacenters and specialized service networks, perhaps, but not 
internet service providers. Mainly because the internet is a relatively lossy 
beast with several performance inhibitors that constantly lie outside an 
operator’s control (i.e. bad filters seem to break the entire United States 
eastern seaboard at least once a year.) I’d wager most of us are not concerned 
with the kind of failure scenario you’re describing simply because there is no 
demand from our customers for sub-millisecond remediation. At least not from 
the ones who are willing to pay for it. 

---

Chris

From: NANOG  On 
Behalf Of Matthew Nance Hall
Sent: Friday, August 5, 2022 12:24 PM
To: nanog@nanog.org
Cc: 'Ramakrishnan Durairajan' ; 'PAUL R BARFORD' 
; klaus-tycho.foers...@tu-dortmund.de
Subject: Question re. operator tools - somewhere betwixt fast failover and TE

You don't often get email from 
mh...@cs.uoregon.edu. Learn why this is 
important

Hello,

I'm Matthew Nance-Hall (Matt), a PhD Candidate at the University of Oregon 
working with Prof. Ram Durairajan (UO), Prof. Paul Barford (UW-Madison) and 
Prof. Klaus-Tycho Foerster (TU Dortmund).

I was hoping someone could shed operator perspective on a research question 
we're exploring. We're interested in the timescales and mechanisms used to 
adjust data paths and wondering where gaps might exist between traffic 
engineering (TE), fast fail-over, and routing.

We're specifically curious about spatio-temporal characteristics where gaps 
might exist. For example, the topological scope of an event (congestion or 
outage) and the timescale for adjustments to be made. I'm aware there are 
operator tools such as fast fail-over and TE for making changes confined to 
single links or across the whole network but wonder if there is a place for 
events that have broader scope (beyond a single link but less than the whole 
network) where new inquiry and exploration would be welcome.

Thank you,
Matt

RE: What say you, nanog re: Starlink vs 5G?

[Chris Wright]

The term "5G" among technical circles started vague, became better defined over 
the course of several years, and is becoming vague again. This nuance was never 
well understood in the public eye, nor by mass publications like CNN. This is a 
battle for 12GHz, not 5G.

Chris


-Original Message-
From: NANOG  On 
Behalf Of John Levine
Sent: Thursday, June 23, 2022 9:45 PM
To: nanog@nanog.org
Subject: Re: What say you, nanog re: Starlink vs 5G?

It appears that Eric Kuhnke  said:
>Adding a terrestrial transmitter source mounted on towers and with CPEs 
>that stomps on the same frequencies as the last 20 years of existing 
>two way VSAT terminals throughout the US seems like a bad idea. Even if 
>you ignore the existence of Starlink, there's a myriad of low bandwidth 
>but critical SCADA systems out there and remote locations on ku-band 
>two way geostationary terminals right now.

I think the original thought was that the satellite service would be used in 
rural areas and 5G in cities so there'd be geographic separation, but Starlink 
is selling service all over the place.

RE: ARIN POC RegDate...

[Chris Wright]

That's just the Unix epoch time. Your info is missing for that field so the 
32-bit integer is a string of 0's, which renders out to 00:00:00 UTC January 
1st 1970.



-Original Message-
From: NANOG  On 
Behalf Of b...@theworld.com
Sent: Sunday, October 24, 2021 8:59 PM
To: nanog@nanog.org
Subject: ARIN POC RegDate...


Perhaps silly but am I the only one with an ARIN POC RegDate of 1970-01-01? 
I've been in that db a long time but not quite that long.

Does it matter? I have no idea what the correct date might be so the 
instructions to correct don't help.

If I needed that info I'd consult the ARIN DB but I guess not.

I guess I'm wondering if it's just their temporary DB glitch so I should ignore 
it.

The rest of the info is perfect beyond my wildest dreams.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*