Re: V6 still not supported

On 3/10/22 9:22 PM, Masataka Ohta wrote: Matthew Walster wrote: IPv6 is technologically superior to IPv4, there's no doubt about that. It is not. Though IPv6 was designed against OSI CLNP (with 20B, or, optionally, 40B addresses), IPv6 incorporated many abandoned ideas of CLNP and XNS

Re: Making Use of 240/4 NetBlock Re: 202203162242.AYC

Hi, Fred: 1)    " ... you will need to replace the existing DNS and DHCP systems...  ":    I am glad that you have touched the next level of considerations. Operating an RAN with one 240/4 netblock, there will be more than enough IP addresses to assign to all client premises. So, the EzIP

Re: V6 still not supported

I'd flagged this to reply, but sadly am a bit behind On 3/10/22 11:02 AM, Matthew Walster wrote: IPv6 is technologically superior to IPv4, there's no doubt about that. It is vastly inferior when it comes to understanding what is going on by your average sysadmin, network engineer, IT

Re: V6 still not supported

> > Let me say that again. Among all the reasons why IPv6 didn't take > > over the world, NONE of them is "because we spent all our time > > improving IPv4 standards instead". > > I'll somewhat call bullshit on this conclusion from the data > available. True, none of the reasons directly claim

Re: Regarding BGP offloading

IOS- XR and Junos (don’t know about others) expose service level APIs that allow offbox best path selection and consequently injecting these back into RIB. FRR is in process of implementing customized best path using lua scripts. Cheers, Jeff > On Mar 16, 2022, at 16:15, Anurag Bhatia wrote: >

Re: Regarding BGP offloading

more details on the particular implementation https://www.cs.princeton.edu/courses/archive/fall17/cos561/papers/espresso17.pdf On Wed, Mar 16, 2022 at 6:14 PM Anurag Bhatia wrote: > > Hello NANOG! > > > I have seen limited talks about offloading of BGP as a whole into > containers/VMs etc. Take

Re: Regarding BGP offloading

One way to do it https://inog.net/files/iNOG14v_oliver_sourcerouting.pdf On Wed, Mar 16, 2022 at 6:14 PM Anurag Bhatia wrote: > > Hello NANOG! > > > I have seen limited talks about offloading of BGP as a whole into > containers/VMs etc. Take e.g this old Google blog post from 2017. Quoting >

Regarding BGP offloading

Hello NANOG! I have seen limited talks about offloading of BGP as a whole into containers/VMs etc. Take e.g this old Google blog post from 2017.

Re: Not Making Use of 240/4 NetBlock

It’s a business problem for the RIR’s. Selling / leasing known defective products is against lots of consumer law. -- Mark Andrews > On 17 Mar 2022, at 03:43, Owen DeLong wrote: > >  > >>> On Mar 15, 2022, at 19:23 , Mark Andrews wrote: >>> >>> >>> On 16 Mar 2022, at 02:54, Owen

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

I have qualms about these drafts also. However, even if the IETF does not move forward with any of them (not even to adopt them as WG items), that doesn’t mean they never will. Times change. Circumstances change. The IETF has changed its position on several (IMO) key issues during its

Re: "Permanent" DST

It appears that Chris Adams said: >Once upon a time, Owen DeLong said: >> You’re right… Two changes to a single file in most cases: >> >> 1. Set the correct new timezone (e.g. MST for California). > >And now your system displays wrong info 100% of the time, since as I >understand it, the

Re: "Permanent" DST

It appears that Jay Hennigan said: >Some systems are dumbed-down with drop-down menus listing cities like >"Americas-Los Angeles" and similar. These will require a bit of work on >the back end. Unix and linux systems have a timezone database that has the historic time zones for everywhere they

Re: "Permanent" DST

This is a weirdly long thread, mostly unrelated to NANOG, it seems. The work for how this will be implemented in most of our computers happens on the TZ list by thoughtful people with lots and lots of experience on the subject: https://mm.icann.org/pipermail/tz/ I believe the last change in

Re: "Permanent" DST

  On 3/16/2022 7:11 AM, John Levine wrote: It appears that Aaron C. de Bruyn via NANOG said: All that's left to solve is in-person stuff...which already currently sucks. "My flight leaves at 6 AM local time and lasts 90 minutes, but I'm crossing 3 timezones heading west...

Re: "Permanent" DST

On Wed, Mar 16, 2022 at 10:31 AM Owen DeLong via NANOG wrote: > > > You’re right… Two changes to a single file in most cases: > > 1. Set the correct new timezone (e.g. MST for California). > 2. Turn off the Daylight Stupid Time flag. > > This doesn't work at all if you want to properly

Re: "Permanent" DST

On 3/16/22 10:41, Jay R. Ashworth wrote: Have we not learned, yet, the "don't lie to the computers" rule? How *would* the timezone libraries handle "DST always on"? They would still have to flap, twice a year, right? It depends. The easy ones have two settings with an optional third. 1.

Re: "Permanent" DST

Once upon a time, Owen DeLong said: > You’re right… Two changes to a single file in most cases: > > 1.Set the correct new timezone (e.g. MST for California). And now your system displays wrong info 100% of the time, since as I understand it, the zones will be changed (e.g. for me, CST will

Latest from ICANN: Quantum Computers + N85 Peering Forum

Latest from ICANN: Quantum Computers are "Interesting"… But Don't Lose your Head *An Interview with ICANN, Paul Hoffman* In a recent publication, written by ICANN (Internet Corporation for Assigned Names and Numbers), chief technology officer Paul Hoffman discussed the hot topic of Quantum

[NANOG-announce] Latest from ICANN: Quantum Computers + N85 Peering Forum

Latest from ICANN: Quantum Computers are "Interesting"… But Don't Lose your Head *An Interview with ICANN, Paul Hoffman* In a recent publication, written by ICANN (Internet Corporation for Assigned Names and Numbers), chief technology officer Paul Hoffman discussed the hot topic of Quantum

Re: V6 still not supported

My answer is to work on resolving the barriers to v6 instead of wasting time on this, yes. Owen > On Mar 16, 2022, at 11:12 , David Bass wrote: > > So your answer is do nothing because we should be spending the time on v6? > > There are a lot of barriers to v6, and there is no logical

Re: "Permanent" DST

> On Mar 16, 2022, at 10:41 , Jay R. Ashworth wrote: > > - Original Message - >> From: "Owen DeLong" > >> No development really necessary… Just pick the corresponding standard-time >> timezone and turn off the DST flip flopping. >> >> E.g. if you are in California and go always-on,

Re: V6 still not supported

So your answer is do nothing because we should be spending the time on v6? There are a lot of barriers to v6, and there is no logical reason why this range of v4 subnets wasn’t made available to the world a decade (or two) ago. The next best time to do it is now though. On Wed, Mar 16, 2022 at

Re: "Permanent" DST

> On Mar 15, 2022, at 12:44 , Jay Hennigan wrote: > > On 3/15/22 12:26, Ray Van Dolson via NANOG wrote: >> I think this is essentially the bill: >> https://www.congress.gov/bill/117th-congress/house-bill/69/text >> Not finding anything about 15 degrees. > > The 15 degrees is kind of a joke.

Re: "Permanent" DST

> > 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:

Re: "Permanent" DST

15 degrees east is Jay’s snarky way of describing permanently putting everyone on a timezone that was formerly applicable to a position roughly 15º east of their current position. In other words, Permanent Daylight Savings time. Owen > On Mar 15, 2022, at 12:19 , Mel Beckman wrote: > > I

Re: "Permanent" DST

- Original Message - > From: "Owen DeLong" > No development really necessary… Just pick the corresponding standard-time > timezone and turn off the DST flip flopping. > > E.g. if you are in California and go always-on, then simply mark it as MST > year > round. > (i.e. just like you’re

Re: "Permanent" DST

> On Mar 15, 2022, at 15:05 , Jan Schaumann via NANOG wrote: > > Dave wrote: >> Folks for most systems, this is a change to a single file. Not a really hard >> thing to accomplish > > Oh, hah, good one. > > I twitch with mild PTSD thinking about the last time > there was change to DST in

Re: "Permanent" DST

It appears that Aaron C. de Bruyn via NANOG said: >All that's left to solve is in-person stuff...which already currently sucks. > >"My flight leaves at 6 AM local time and lasts 90 minutes, but I'm crossing >3 timezones heading west... It could be worse. In non-COVID times there are flights

Re: V6 still not supported

> On Mar 16, 2022, at 12:20 PM, Owen DeLong via NANOG > wrote: > >> >> What struck me is how NONE of those challenges in doing IPv6 deployment >> in the field had anything to do with fending off attempts to make IPv4 >> better. >> >> Let me say that again. Among all

Re: "Permanent" DST

> On Mar 15, 2022, at 17:34 , Chris Adams wrote: > > Once upon a time, Dave said: >> Folks for most systems, this is a change to a single file. Not a really hard >> thing to accomplish > > For lots of up-to-date servers running a current and well-maintained > operating system, this will be

Re: Not Making Use of 240/4 NetBlock

> On Mar 15, 2022, at 19:23 , Mark Andrews wrote: > > > >> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG wrote: >> >> Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able >> to claim some detailed knowledge on the subject. >> >> In general, the RIRs themselves

Re: "Permanent" DST

> On Mar 15, 2022, at 22:16 , Doug Barton wrote: > > All of this. The reason that the proposal is always worded "Permanent > Daylight Savings Time" is that there are a non-trivial number of people who > genuinely believe that with DST we get more sunlight. Not more sunlight > during the

Re: V6 still not supported

> > What struck me is how NONE of those challenges in doing IPv6 deployment > in the field had anything to do with fending off attempts to make IPv4 > better. > > Let me say that again. Among all the reasons why IPv6 didn't take > over the world, NONE of them is "because we spent all our time >

Re: "Permanent" DST

No development really necessary… Just pick the corresponding standard-time timezone and turn off the DST flip flopping. E.g. if you are in California and go always-on, then simply mark it as MST year round. (i.e. just like you’re in Arizona today, which is MST year round, no DST). Owen > On

Re: "Permanent" DST

> "My flight leaves at 6 AM local time and lasts 90 minutes, but I'm crossing 3 > timezones heading west...so you need to pick me up at...uh4:30 AM your > time? Oh waitare you currently in DST or not because we don't do DST > here, but I think you doso you either need to pick me

Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC

> > 2)Re: Ur. Pt. 2) " So replace every CPE device, including ... ": > It is evident that you even did not glance at the EzIP Draft Abstract > before commenting, but just relying on your recollection of the past 240/4 > efforts. Please spend a minute or two on reading the EzIP Abstract. In

Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC

Hi, Mark: 1)    Re: Ur. Pt. 1)  " ISE != IETF. ...   ":    On a public forum like NANOG, it is much more expeditious to provide forward guidance than reciting past failures, especially those of a third party due to improper system setup. 2)    Re: Ur. Pt. 2) " So replace every CPE device,

Re: "Permanent" DST

On Tue, Mar 15, 2022 at 3:09 PM Joe Greco wrote: > We COULD all work in UTC and un-learn the weird system of hour offsets > and timezones. This would be convenient for people at a distance, since > it would be simply a matter of stating availability hours, rather than > giving someone hours AND

Re: "Permanent" DST

> On Mar 15, 2022, at 1:24 PM, Elmar K. Bins wrote: > > 2 - I like how american politics is capable of creating new problems; where > did this bill come from in the first place? And who's lobbying? According to the universal time law, the US is on Standard Time unless a state chooses

Re: "Permanent" DST

"Farmers work on that kind of schedule" With GPS and now even RTK-assisted GPS, farmers don't care if it's noon or midnight, though obviously working near normal human awake times makes the search for labor easier. - Mike Hammett Intelligent Computing Solutions Midwest Internet

Re: "Permanent" DST

Always on or always off, I don't care which, just pick one and give sufficient lead time for development. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Jay R. Ashworth" To: "nanog@nanog.org list"

Re: "Permanent" DST

On 2022-03-16, at 13:26, Tom Beecher wrote: > > I certainly can't find any references to a massive uptake in kids getting > doinked by cars at dark bus stops in that 70s experiment. Of course not. The game is that at least one kid will die in the time an experiment runs, and the press will

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

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

Re: "Permanent" DST

> > They don't want their names on it when what happened in the 70s happens > again. The effect of setting everything to DST and staying there is that in > the winter, especially in the norther latitude it will be pitch dark during > most of the morning when children get picked up at school bus

Re: Sprint contact - stop bgp announcement

Hi Elvis, you can reach Sprint at ipc...@t-mobile.com Regards, - Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: ma...@paesani.it Il giorno mer 16 mar 2022 alle ore 09:41 Elvis Daniel Velea ha scritto: > Hi, > > I am looking for a

Re: V6 still not supported

It is great to see NANOG members describing some of the real barriers to widespread IPv6 deployment. Buggy implementations, lack of consumer demand, too many other things to do (like rapidly deploying fiber to customers before they switch to a competitor), lack of IPv6 expertise at ISPs, lack of

Sprint contact - stop bgp announcement

Hi, I am looking for a Sprint/T-mobile contact that can help stop the bgp announcement of 45.158.132.0/22 from AS1239. If questions, please contact me offlist. Thank you, Elvis