Re: home router battery backup

[Mark Tinka]

On 1/18/22 22:27, Jordan Hazen wrote:


Yes, but separate from their absolute low-voltage cutoff meant to
protect battery cells, these hybrid storage products include a
user-adjustable reserve setpoint, meant to balance their backup
role with grid support and peak-shaving.


Yes. In the traditional battery inverter world, it's called "increased 
self-consumption" :-).




Owners of home-scale PV+battery systems often sign up for
time-of-use utility tariffs, where per-kWh rates are high during
peak periods (day and evening), but very low at night.  With a
large enough system at full charge, such homes can then run
autonomously for several hours after sunset, covering most or all
of the peak-demand period, before switching back to grid power, and
optionally recharging at night when rates and demand are low (if
local solar production alone isn't enough replenishment).


Indeed.

Obviously, if your goal is to reduce power costs, then this is fine. The 
potential downside is consistent cycling of the battery, which will 
reduce it lifespan.


Then again, batteries are getting cheaper (at least the LFP chemistry), 
so perhaps it might not matter much after you get a solid 5 - 8 years, 
at the very least, out of them.




Of course, letting the battery discharge all the way to its 0%
safety limit in its daily demand shifting role, besides prematurely
aging the cells, would leave the owner without backup were an
outage to strike at a bad time, in late afternoon or evening.


Agreed.

Between the battery and inverter OEM's, they might not let you get that low.



With the utility paying for and managing distributed batteries
itself, though, they'd want to derive the greatest possible return
on their investment, and so probably tend to set that reserve-limit
very low.


I know that there are some markets where home owners are given 
incentives to buy batteries that they can use to take some load off the 
grid. Do you know of any markets where this is actually being done by 
the utility, including remote control?




Some utilities have been experimenting with using these storage
systems as part of demand-side management / load shedding, where
during peak periods they can signal for buildings capable of
operating from battery power to start doing do for a set period of
time.  With enough aggregate storage available, this could avoid
having to fire up an expensive-to-operate natural gas peaker plant.


I know the Australians have been fiddling around with remote management 
of HVAC and water heating systems as part of their demand-side 
management program. However, I don't think there is sufficient scale to 
help them reduce production enough so as to continue their use of fossil 
fuels.


Theoretically, it's a great idea. I just don't see it in practice at 
scale, for an entire nation, managed by the utility.




The battery system owner would receive bill credits, lower rates,
or other incentives in exchange for allowing this, similar to how
some data centers and other industrial building will be compensated
for proactively switching to generator power when asked to during a
high-demand period.


I've always been a supporter for micro grids... either at the home 
level, or the neighborhood level. It's easier to manage your usage when 
you know how much energy you have for the day.


I don't think renewables at grid scale will work, because the user has 
no visibility of generation capacity and constraints. They'll just keep 
flipping switches.


So if we can put generation responsibility in the hands of the user, 
there is a decent chance that renewables may actually work. Plus, we use 
less land.




Is anyone aware of data centers yet leveraging battery storage for
a similar purpose?  It would make zero economic sense with
traditional lead-acid storage, of course, due to such batteries'
limited cycle life and intolerance of deep discharge.


I can't imagine any data centre using the battery for pure base load. 
Like they do with UPS's now, I'd expect the battery is really there to 
provide load management between grid loss and activation of the 
generator. You only need the battery for a few seconds to a couple of 
minutes.


So no different from what they are currently doing with Lead Acid 
batteries, but with the benefit of more cycles, deeper discharging, 
higher energy density, less weight and less space, from Li-Ion.




Uilities are becoming increasingly hostile to solar net-metering,
where PV system owners are credited for excess energy supplied to
the grid during peak sun hours, then allowed to "draw this back" at
parity after sunset, using the grid as a sort of virtual battery.
They argue that such use incurs uncompensated costs (see "duck
curve"), and have successfully lobbied for tariff changes in some
areas to limit or end the practice.  Other locales have never had
net-metering.  On-site storage can be a good alternative to net
metering where it's unavailable, and is probably more beneficial to

Re: What do you think about this airline vs 5G brouhaha?

[Brandon Martin]

On 1/19/22 12:28 AM, Masataka Ohta wrote:

Digital technology can not be useful when RF stage is saturated,
which is why a patent to avoid saturation was essential for CDMA. 


Completely overloading the receiver frontend will of course render any 
kind of modulation or coding gain irrelevant, yes.


However, as long as your receiver still has adequate dynamic range to 
receive "everything that's there", effective gain via spread spectrum, 
FEC, etc. can be on the order of 20-30dB compared to a naive narrowband 
system operating at similar power when faced with a "jammer" within your 
RF receive mask, which is what I was getting at.


In this case, however, the system is basically a dumb radar, apparently, 
so none of that is going to be present. The fact that a signal 250MHz 
out of band can present meaningful issues is troubling nonetheless.


--
Brandon Martin

Re: home router battery backup

[Mark Tinka]

On 1/18/22 23:17, Joe Maimon wrote:



The inverter in question is the one being utilized in conjunction with 
the powerwall, ats, solar array. All nicely done and reliable and 
wired in already and with proper capacity.


Being able to call for and get more DC power on demand would make this 
a true uninterruptible solution.


Running a gen to support the battery means the gen size does not need 
to correlate at all with the peaks and surges of demand and can run at 
maximum efficiency and we can avoid unbalanced leg problems and other 
voltage variation issues that can happen with portable gens.


Programming comes into play for automated monthly testing, capacity 
prediction, even spot costing of utility power. Between the grid, the 
solar array, time of day, season, weather, battery level, generator 
input, load characteristics, outage duration, grid costs/stresses 
there can be a lot of factors that might need a bit more balancing and 
programming than you might typically expect available from any half 
decent battery inverter, but might find a nice place in a truly fully 
integrated home UPS solution.


Integrate it enough and perhaps the gen/rectifier components would 
even fit into typical residential facilities spaces and this sort of 
setup could be all the more typical and standard.


I use SMA... both for PV and battery inversion. It's an AC-coupled 
system, with the battery inverter being at the core of the system.


Both the PV and battery inverters are highly-configurable, and out the 
box, will do a lot of things reasonably well.


However, it took me about 8 months to properly set this system up for 
our requirements, because, as you say, you need to get a lot of things 
right on a number of separate systems (in an AC-coupled design) to get 
the most out of your installation.


For us, we have a system large enough to be off-grid 100% of the time. 
However, we want to lengthen the lifespan of the battery, by keeping 
charge voltage low, and not discharging it too much. So we struck a 
balance between using the grid significantly less than we used to before 
we could self-generate, and keeping the battery voltage low (charge to 
about 78% SoC, discharge to about 65% SoC). Of course, in the case of a 
utility outage, we shall charge to 100%. Luckily, during those outages, 
we've not had to dip below 35% SoC when the outage is throughout the 
night, and into the morning when the sun is out. The pack is a 48V, 
33.6kWh, 700Ah system.


So yes, even the most sophisticated inverters may still need some user 
input. The most important thing is to understand what you want to get 
out of the system (do you want to go off-grid, do you want to stay 
on-grid but save a little utility cash or do you just want backup 
protection for a couple of hours?), find an inverter that can provide 
that, and spend several weeks to a few months fine-tuning the 
installation once the installers leave.


Mark.

Re: home router battery backup

[Mark Tinka]

On 1/18/22 22:31, Michael Thomas wrote:



I have a SolarEdge inverter and they are still working on the 
software. I don't know if that's true across their product line, but I 
would think that the software would be pretty portable.


SMA on this side. Highly configurable, and you don't even need to be 
next to it (all web-based).


Mark.

Re: What do you think about this airline vs 5G brouhaha?

[Masataka Ohta]

Brandon Martin wrote:

The system apparently also responds poorly to both narrowband and 
wideband jammers i.e. it does not employ what we'd consider robust, 
modern error-correction or coding systems or even digital error checking 
techniques.


Digital technology can not be useful when RF stage is saturated,
which is why a patent to avoid saturation was essential for CDMA.

Masataka Ohta

Re: What do you think about this airline vs 5G brouhaha?

[Masataka Ohta]

Jay Hennigan wrote:


Radar receivers are typically some form of direct conversion with
rather good selectivity, synchronized to the frequency of the
transmitted pulse.


No. Direct conversion stage has no inherent frequency
selectivity and is subject to saturation by noise of
any frequency unless the noise is removed in advance.

Selectivity can be enjoyed only after successful
unsaturated conversion, direct or to IF.

But, the solution is to put an LC band pass/stop filter
between an antenna and a receiver, though I have no
idea on the difficulty to obtain FAA/FCC approval to
do so.

Masataka Ohta

Coverage of the .to internet outage

[Jay R. Ashworth]

This piece:

https://www.npr.org/2022/01/18/1073863310/an-undersea-cable-fault-could-cut-tonga-from-the-rest-of-the-world-for-weeks

drills down to this piece with slightly more detail:

https://www.reuters.com/markets/funds/undersea-cable-fault-could-cut-off-tonga-rest-world-weeks-2022-01-18/

I'm told their national carrier is trying to bring in a ground station as 
well, though not whom it will connect to.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: What do you think about this airline vs 5G brouhaha?

[Brandon Martin]

On 01/18/2022 20:08, Michael Loftis wrote:
Remember that the RA is sub 1W looking for reflected emissions. It’s 
very possible the ground equipment for a cell base station to have 
spurious harmonics…where they land requires more RF engineering chops 
than I’ve got, and would obviously be very system dependent. So yes in 
my understanding due to the RF voodoo of how they transmit and receive


This is run-of-the-mill testing for not just transmitters but anything 
that could possibly, maybe, emit RF energy in the USA.  The out-of-band 
(spurious emission) limits are quite strenuous, and the test criteria 
are specifically designed to catch even fairly intermittent blips that 
might crop up just about anywhere let alone in a band of particular 
interest.  There's a reason (just about) all FCC compliance houses have 
70GHz spectrum analyzers even if they don't normally look at intentional 
emissions above 6 or so.


One thing the FCC could potentially do to wipe some egg of their 
collective faces, here, is mandate that transmitters operating in this 
newly allocated wireless band face additional scrutiny for spurious 
emissions in the radio altimeter band as well as the guard band between 
the two services and a similar bandwidth above the radio altimeter band. 
 If the quasi-peak detector runs across that swath for an hour while 
the operating conditions of the device being tested are continuously 
varied both within and somewhat outside its normal and even 
extraordinary (but functional) operating range and still doesn't see 
anything that isn't outside the femtowatt range, you're probably good. 
FAA and aviation industry can even advise on these standards.  That's 
not unheard of and a good example of industry cooperation.


Note that this would be above and beyond the existing general rules for 
spurious emissions that are already tested as part of pretty much any RF 
transmitter in the USA.


I'm curious at what point the possibility of spurious emissions from an 
old-fashioned TVRO C-Band receiver becomes concerning.  It would be very 
sporadic, but the gain off the ground station dish is rather 
non-trivial.  AFAIK, the design of most receivers would mean it would 
have to be a modulation product of two LOs, but I suspect it's possible 
to have something come within 500MHz of this band just like this 
wireless allocation does.  Those users have been around for 35+ years 
and are widespread and unlicensed (as they are receive only).


--
Brandon Martin

Re: What do you think about this airline vs 5G brouhaha?

[John Levine]

It appears that Michael Thomas  said:
>
>I really don't know anything about it. It seems really late to be having 
>this fight now, right?

Harold Feld did an excellent explainer about this in November:

https://wetmachine.com/tales-of-the-sausage-factory/what-the-eff-faa-my-insanely-long-field-guide-to-the-faa-fcc-5g-c-band-fight/

tl;dr while interference is certainly possible in theory, the putative
evidence can charitably be described as weak, and the FAA has been
complete jerks throughout the process.

R's,
John

Re: What do you think about this airline vs 5G brouhaha?

[Lady Benjamin Cannon of Glencoe, ASCE]

Interference with radar altimeters is a serious issue.   As a pilot myself, if 
this fails, you crash with all hands lost.  

That said, we should be able to eliminate the possibility of any interference. 

So this shouldn’t be a thing.

But also, you don’t f- with radar altimeters.

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
l...@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the 
world.”

FCC License KJ6FJJ

Sent from my iPhone via RFC1149.

> On Jan 18, 2022, at 12:32 PM, Michael Thomas  wrote:
> 
> I really don't know anything about it. It seems really late to be having this 
> fight now, right?
> 
> Mike

Re: What do you think about this airline vs 5G brouhaha?

[Michael Loftis]

On Tue, Jan 18, 2022 at 17:49 Jay Hennigan  wrote:

> On 1/18/22 15:51, Brandon Martin wrote:
>
> > Further, it seems that good engineering practice was not used in the
> > design of these vulnerable systems and that they are subject to
> > interference from broad-spectrum "jammers" (i.e. signals that, in terms
> > of modulation and timing, don't necessarily correspond to what they're
> > expecting to receive) transmitting well outside their allocated band (by
> > separation comparable to the entire band in which they operate) let
> > alone outside the expected, tuned frequency of signal reception.  All of
> > these are typically very high on the list of consideration when
> > designing an RF receiver and seem to have been either ignored entirely
> > or at least discounted in the design of these instruments from what I'm
> > hearing.
>
> This simply doesn't make sense. Radar receivers are usually direct
> conversion driven from the same frequency source as the transmitter,
> meaning that they are going to have rather good selectivity with regard
> to frequency.
>
> Furthermore, a radio altimeter used for approach and landing is going to
> have a very short time window. I'm by no means familiar with the
> internal workings of these devices, their specifications, or their
> effective range, but if the altitude to be measured is 5000 feet or less
> the device will send a pulse and then open a receive window of no more
> than about 11 microseconds to look for its return. If you're only
> concerned about being 1000 feet or less above terrain, the window is
> about 2 microseconds. The pulses are presumably sent relatively
> frequently, probably several times a second, and the results averaged.
> In addition, the radar antenna beamwidth is going to be relatively small
> and pointed more or less straight down.


GPWS, and all rescue/medevac/etc helicopter operations also use the RA, and
this is NOT just in the landing/approach of a runway. Think about landing a
helicopter at night on the  freeway or a nearby field. TAWS uses GPS to
locate in space and I don’t know where it’s altitude source is - probably
the baro altimeter until the RA starts getting a return (or thinks it is)


>
> Intentional broadband jamming isn't going to be very effective against
> an airplane as the jammer would need to be directly beneath a fast
> moving target and get the timing exactly right with microsecond accuracy.
>
> Accidental interference from a source at least 220MHz out of band with a
> beam pointed at the horizon is even more far-fetched unless, as you say,
> the radar unit's receiver is complete garbage in which case how did it
> get a TSO in the first place? Avionics equipment that is critical to a
> precision approach isn't, or at least shouldn't be, crap.


They’ve never been required to have immunity. Last spec update was AFAIK
1980s. It’s definitely a stack of problems…part of which is the FCC
auctioning the Spectrum, it puts them in conflict as both the enforcement
and beneficiary. Billions of dollars being the CTIA on one hand. On the
other RTCA, AOPA, and some other small $ fish they stand nothing to gain
from.

Remember that the RA is sub 1W looking for reflected emissions. It’s very
possible the ground equipment for a cell base station to have spurious
harmonics…where they land requires more RF engineering chops than I’ve got,
and would obviously be very system dependent. So yes in my understanding
due to the RF voodoo of how they transmit and receive, and the .. field of
view .. those factors mitigate interference for certain…but why did the FCC
auction that chunk? Why not say ok you’ve got two years to develop a
standard, update that 1980s requirement, and 5 or 10 to implement? Instead
we’re just barely four years on and going to be seeing potentially
interesting deployments.  Interference that only can happen and only
matters in critical flight phases….





>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>
-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: What do you think about this airline vs 5G brouhaha?

[Brandon Martin]

On 01/18/2022 19:48, Jay Hennigan wrote:
Intentional broadband jamming isn't going to be very effective against 
an airplane as the jammer would need to be directly beneath a fast 
moving target and get the timing exactly right with microsecond accuracy.


Just to clarify, I wasn't referring to intentional (and naive) "jammers" 
that simply attempt to disable a system, here, but rather using a more 
academic notion of the concept to refer to a 5G NR system acting in an 
unintentional context with the same outcome similar to how one might 
consider modern OFDM-based WiFi a "jammer" to a conventional narrowband 
communication system operating on the same or a nearby carrier frequency 
like the classic Bluetooth PHY.


5G NR is (or should be, from what I know of it and its relation to other 
OFDM systems) a pretty broad-band, flat-spectrum PHY operating at only 
moderate power and for essentially infinite duration in the scope of a 
radar receiver.  It would by no means be an ideal means to disable such 
a system, but it does represent RF energy that the receiver needs to 
contend with.


--
Brandon Martin

Re: What do you think about this airline vs 5G brouhaha?

[Jay Hennigan]

On 1/18/22 15:51, Brandon Martin wrote:

Further, it seems that good engineering practice was not used in the 
design of these vulnerable systems and that they are subject to 
interference from broad-spectrum "jammers" (i.e. signals that, in terms 
of modulation and timing, don't necessarily correspond to what they're 
expecting to receive) transmitting well outside their allocated band (by 
separation comparable to the entire band in which they operate) let 
alone outside the expected, tuned frequency of signal reception.  All of 
these are typically very high on the list of consideration when 
designing an RF receiver and seem to have been either ignored entirely 
or at least discounted in the design of these instruments from what I'm 
hearing.


This simply doesn't make sense. Radar receivers are usually direct 
conversion driven from the same frequency source as the transmitter, 
meaning that they are going to have rather good selectivity with regard 
to frequency.


Furthermore, a radio altimeter used for approach and landing is going to 
have a very short time window. I'm by no means familiar with the 
internal workings of these devices, their specifications, or their 
effective range, but if the altitude to be measured is 5000 feet or less 
the device will send a pulse and then open a receive window of no more 
than about 11 microseconds to look for its return. If you're only 
concerned about being 1000 feet or less above terrain, the window is 
about 2 microseconds. The pulses are presumably sent relatively 
frequently, probably several times a second, and the results averaged. 
In addition, the radar antenna beamwidth is going to be relatively small 
and pointed more or less straight down.


Intentional broadband jamming isn't going to be very effective against 
an airplane as the jammer would need to be directly beneath a fast 
moving target and get the timing exactly right with microsecond accuracy.


Accidental interference from a source at least 220MHz out of band with a 
beam pointed at the horizon is even more far-fetched unless, as you say, 
the radar unit's receiver is complete garbage in which case how did it 
get a TSO in the first place? Avionics equipment that is critical to a 
precision approach isn't, or at least shouldn't be, crap.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: What do you think about this airline vs 5G brouhaha?

[Brandon Martin]

On 01/18/2022 16:57, Mel Beckman wrote:

Bo, it’s the radar altimeter, not the barometric altimeter. This is a radar 
distance measurement device for determine the precise height above the ground,  
critical for low-visibility approaches.

Where frequency interference is concerned, under FCC rules the existing users 
have priority, and are entitled to interference-free operation.


Hmm, I'm seeing that "radar altimeter" and "radio altimeter" can indeed 
refer to the same class of instrument, so perhaps there's confusion 
(perhaps including by myself).


Nonetheless, while indeed existing users are granted some reprieve from 
interference by new users of other services, this is mostly in the 
planning stage of things and not the actual operations.  The time to get 
this addressed would have been back when this portion of the band was 
re-allocated to wireless systems (from space-to-ground satellite 
systems) several years ago.


Further, it seems that good engineering practice was not used in the 
design of these vulnerable systems and that they are subject to 
interference from broad-spectrum "jammers" (i.e. signals that, in terms 
of modulation and timing, don't necessarily correspond to what they're 
expecting to receive) transmitting well outside their allocated band (by 
separation comparable to the entire band in which they operate) let 
alone outside the expected, tuned frequency of signal reception.  All of 
these are typically very high on the list of consideration when 
designing an RF receiver and seem to have been either ignored entirely 
or at least discounted in the design of these instruments from what I'm 
hearing.


That is, I have yet to see any source (even from the aviation industry) 
claiming that there is in-band interference issues from the new wireless 
systems or that these radio altimeter systems somehow need such extreme 
receiver sensitivity that a several hundred-MHz guard band between 
services (with an existing service in between, albeit one with the 
transmitter usually in the other direction) is not sufficient to ensure 
proper receiver isolation from unwanted signals.

--
Brandon Martin

Re: What do you think about this airline vs 5G brouhaha?

[Michael Loftis]

New to the public eye but not orgs like AOPA who’ve been fighting since
2020 but there not multi billion dollar lobby groups. US is more affected
because we have more general aviation, and an older fleet overall.

And it’s not cheap to replace these radio altimeters (but that’s kind of
like everything aviation)

On Tue, Jan 18, 2022 at 13:32 Michael Thomas  wrote:

>
> I really don't know anything about it. It seems really late to be having
> this fight now, right?
>
> Mike
>
> --

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: What do you think about this airline vs 5G brouhaha?

[Brandon Martin]

On 1/18/22 5:06 PM, Mel Beckman wrote:
Incorrect. Owning spectrum also includes the right to 
interference-free operation. And you imply that the FAA and airline 
industry has done nothing, when in reality it’s the FCC who has done 
nothing. the FAA sponsored extensive engineering tests that 
demonstrate the interference is a concern, and they notified all the 
parties well in advance. The fCC et al chose to do no research of 
their own, and are basing all their assumptions on operation in other 
countries, which even you must admit can’t really be congruent with 
the US.
Owning spectrum includes the right to interference-free operations from 
IN BAND interference (or not, depending on how you "own" it).


The FAA and airlines are (presumably) correct that there is de-facto an 
interference issue.  The FCC is also (presumably) correct that it's "not 
their problem" as the interference is due to grossly out-of-band 
signals, and the FCC has provided what they believe to be (and, 
according to most RF engineering practices I know of, is) a more than 
sufficient guard band between the two users.


Interference from out-of-band sources is on the operator of the 
receiving equipment to correct EVEN IF they are a licensed, primary user 
of their spectrum since the interference is from outside their 
allocation. This is always true so long as the folks sourcing the 
interference are complying with the limits of their spectrum (there are 
some other wiggles for Part 15 unlicensed users) including power limits 
and applicable transmit spectrum masks.


The FCC's job is to make sure that they set the rules such that folks 
with licensed spectrum do not experience practical problems when 
presented with out-of-band signals. When doing this, they attempt to use 
established guidelines of good engineering practice as well as reports 
from "the field", but they can't possibly account for users with what is 
arguably simply (very) faulty equipment.


If my 1kW HAM FM radio transmitter on 145MHz causes receive problems on 
your aviation band AM receiver (108-137MHz), that is YOUR problem as 
long as I'm complying with all the rules and regs of part 97. That is, 
your receiver sucks, and you need to fix it - possibly by replacing it. 
Likewise, if I'm getting receiver desense issues on my 145MHz FM 
handheld near the airport because of ATC's AM transmitter a few dozen 
MHz down, it's on ME to fix it (or live with it).


The issue that cropped up appears to be that, since the C-band spectrum 
under discussion went unused for so long, a LOT of sucky receivers got 
deployed, and nobody really noticed or cared. Now, it's a big deal to 
try to replace them all, and it's made even worse by how difficult 
changing anything in aviation is and how comparatively old and hence 
simple (perhaps too simple) the radio altimeter RF physical layer 
apparently is.


--
Brandon Martin

Re: What do you think about this airline vs 5G brouhaha?

[Shane Ronan]

Except that the FAA isn't claiming interference in their LICENSED band,
they are claiming interference OUTSIDE their licensed band. You can't squat
on a frequency and then expect the licensed users to accommodate you.

Shane

On Tue, Jan 18, 2022 at 5:06 PM Mel Beckman  wrote:

> Shane,
>
> Incorrect. Owning spectrum also includes the right to interference-free
> operation. And you imply that the FAA and airline industry has done
> nothing, when in reality it’s the FCC who has done nothing. the FAA
> sponsored extensive engineering tests that demonstrate the interference is
> a concern, and they notified all the parties well in advance. The fCC et al
> chose to do no research of their own, and are basing all their assumptions
> on operation in other countries, which even you must admit can’t really be
> congruent with the US.
>
> -mel via cell
>
> On Jan 18, 2022, at 2:01 PM, sro...@ronan-online.com wrote:
>
>  The thing is aviation DOESN’T own this spectrum, they just assumed it
> would always be unused. And they failed to mention it would be a problem
> during the last 5 years of discussion regarding the use of this spectrum.
>
> Shane
>
> On Jan 18, 2022, at 4:25 PM, Mel Beckman  wrote:
>
> 
>
> Michael,
>
>
> Here’s a recent PCmag editorial on the subject, and it seems like many
> people want to put Internet speed above airline safety:
>
>
> https://www.pcmag.com/news/faa-goes-in-hard-to-kill-mid-band-5g
> 
>
>
> This issue definitely impacts network operations for 5G providers, so
> makes sense to discuss here.
>
>
> Here’s a comment from a friend of mine who has been both a network
> engineer and a pilot for United Airlines, posted on the article linked
> above:
>
>
> *“As a pilot, I can tell you that landing in instrument conditions is by
> far the most critical flight regime possible, during which the radar
> altimeter reports are a matter of life and death. There is no alternative
> technology, such as GPS, with the required accuracy and reliability, to
> provide approach guidance down to the runway in zero-zero weather, which is
> what the radar altimeter does. *
>
>
> *The collective tech industry needs to admit that it made a huge blunder
> when it urged the FCC’s clueless Ajit Pai to “blow off” the clearly
> demonstrated FAA spectrum conflict. Sorry, passengers, but if you look out
> your window, you’ll see that aviation owns this spectrum and is entitled to
> interference-free operation. Replacing all radar altimeters isn’t going to
> happen in time for 5G anyway — it took more than ten years just to deploy
> anti-collision technology. So do what you should have done from the
> beginning: follow the FCC rules of non-interference to existing users, who
> have clear priority in this case.”*
>
>
> I tend to agree with him, and it looks like the 5G providers and FAA
> agreed last week to put some buffer safety zones around runway approaches
> at 50 major airports:
>
>
>
> https://www.cnet.com/news/faa-lists-50-airports-getting-temporary-buffer-zones-blocking-new-5g-signals/
> 
>
>
>
> -mel
>
> On Jan 18, 2022, at 12:33 PM, Michael Thomas  wrote:
>
> 
> I really don't know anything about it. It seems really late to be having
> this fight now, right?
>
> Mike
>
>

Re: What do you think about this airline vs 5G brouhaha?

[Jay Hennigan]

On 1/18/22 12:29, Michael Thomas wrote:


I really don't know anything about it. It seems really late to be having 
this fight now, right?


From a technical standpoint it seems to me to be a non-issue. There's a 
220 MHz guard band. 5G signals top out at 3980 MHz and radar altimeters 
operate between 4200 and 4400 MHz.


If a signal 220 MHz away is going to interfere, then radar altimeters on 
other aircraft operating in the same band would clearly be a far greater 
threat, and those radar altimeter signals will be rather numerous near 
airports. In other words, if non-correlated signals 220 MHz away are 
going to interfere, then signals within the same band are going to be a 
far greater source of interference.


Radar receivers are typically some form of direct conversion with rather 
good selectivity, synchronized to the frequency of the transmitted 
pulse. In addition, radar altimeter antennas are pointed at the ground, 
perpendicular to the horizon. Cell site antennas by design are aimed 
more or less toward the horizon, not pointed straight up at the sky.


There's also an existing FCC mobile allocation from 4400 to 4500 MHz 
directly adjacent to the aeronautical radar band on the high side with 
no guard band, yet no complaints about that.


IMNSHO, the concern that 5G cellular signals will cause airplanes to 
fall out of the sky has about this >< much more credence than the 
concern that 5G signals cause coronavirus.


It shouldn't be that hard to instrument an aircraft with test equipment, 
buzz a few operating cell towers, and come up with hard data.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: What do you think about this airline vs 5G brouhaha?

[Nick Hilliard]

Mel Beckman wrote on 18/01/2022 21:25:
/The collective tech industry needs to admit that it made a huge blunder 
when it urged the FCC’s clueless Ajit Pai to “blow off” the clearly 
demonstrated FAA spectrum conflict. Sorry, passengers, but if you look 
out your window, you’ll see that aviation owns this spectrum and is 
entitled to interference-free operation. Replacing all radar altimeters 
isn’t going to happen in time for 5G anyway — it took more than ten 
years just to deploy anti-collision technology. So do what you should 
have done from the beginning: follow the FCC rules of non-interference 
to existing users, who have clear priority in this case.”/


The original fixed satellite comms (space-to-earth) allocation was 
3700-4200MHz, which was split into two parts in 2020: a mobile wireless 
spectrum allocation on 3700MHz to 4000MHz (for 5G) with 4000-4200MHz 
remaining allocated to satellite comms. The 4200-4400MHz range is 
allocated to aeronautical navigation and is used for radio altimeters.


So by rights, aviation doesn't now and never did own this spectrum. 
That said, spectrum bleed on radio transmitters is something that 
happens, and I've no doubt that there are plenty of broken altimeter 
receiver antennas out there which will pick up signals outside their 
formal allocation of 4200-4400MHz.  Regularly tested band pass filters 
should deal with most of this.


Even if technically the aeronautical sector doesn't own this spectrum, 
the consequences of transmitter or receiver bleed from nearby 
allocations could be serious for the same reason that if someone walks 
out on a pedestrian crossing without checking and gets mown down by a 
drunk driver, they're not going to be jubilantly talking at their 
funeral about how at least they were acting within their rights.


Nick

Re: What do you think about this airline vs 5G brouhaha?

[Mike Hammett]

What I've seen so far from the airline industry is a joke. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mel Beckman"  
To: sro...@ronan-online.com 
Cc: nanog@nanog.org 
Sent: Tuesday, January 18, 2022 4:06:46 PM 
Subject: Re: What do you think about this airline vs 5G brouhaha? 

Shane, 


Incorrect. Owning spectrum also includes the right to interference-free 
operation. And you imply that the FAA and airline industry has done nothing, 
when in reality it’s the FCC who has done nothing. the FAA sponsored extensive 
engineering tests that demonstrate the interference is a concern, and they 
notified all the parties well in advance. The fCC et al chose to do no research 
of their own, and are basing all their assumptions on operation in other 
countries, which even you must admit can’t really be congruent with the US. 


-mel via cell 



On Jan 18, 2022, at 2:01 PM, sro...@ronan-online.com wrote: 






The thing is aviation DOESN’T own this spectrum, they just assumed it would 
always be unused. And they failed to mention it would be a problem during the 
last 5 years of discussion regarding the use of this spectrum. 


Shane 




On Jan 18, 2022, at 4:25 PM, Mel Beckman  wrote: 







Michael, 


Here’s a recent PCmag editorial on the subject, and it seems like many people 
want to put Internet speed above airline safety: 


https://www.pcmag.com/news/faa-goes-in-hard-to-kill-mid-band-5g 


This issue definitely impacts network operations for 5G providers, so makes 
sense to discuss here. 


Here’s a comment from a friend of mine who has been both a network engineer and 
a pilot for United Airlines, posted on the article linked above: 


“As a pilot, I can tell you that landing in instrument conditions is by far the 
most critical flight regime possible, during which the radar altimeter reports 
are a matter of life and death. There is no alternative technology, such as 
GPS, with the required accuracy and reliability, to provide approach guidance 
down to the runway in zero-zero weather, which is what the radar altimeter 
does. 


The collective tech industry needs to admit that it made a huge blunder when it 
urged the FCC’s clueless Ajit Pai to “blow off” the clearly demonstrated FAA 
spectrum conflict. Sorry, passengers, but if you look out your window, you’ll 
see that aviation owns this spectrum and is entitled to interference-free 
operation. Replacing all radar altimeters isn’t going to happen in time for 5G 
anyway — it took more than ten years just to deploy anti-collision technology. 
So do what you should have done from the beginning: follow the FCC rules of 
non-interference to existing users, who have clear priority in this case.” 


I tend to agree with him, and it looks like the 5G providers and FAA agreed 
last week to put some buffer safety zones around runway approaches at 50 major 
airports: 


https://www.cnet.com/news/faa-lists-50-airports-getting-temporary-buffer-zones-blocking-new-5g-signals/
 



-mel 



On Jan 18, 2022, at 12:33 PM, Michael Thomas  wrote: 







I really don't know anything about it. It seems really late to be having this 
fight now, right? 

Mike 

Re: What do you think about this airline vs 5G brouhaha?

[Mel Beckman]

Apples and oranges Michael. The US domestic aviation environment is quite 
different than even Europe or and especially smaller countries overseas. And 
how long has 5G been out anyway? I hardly think that’s been available for 
enough of a safety track record in any country.

-mel via cell

On Jan 18, 2022, at 2:06 PM, Mel Beckman  wrote:

 Shane,

Incorrect. Owning spectrum also includes the right to interference-free 
operation. And you imply that the FAA and airline industry has done nothing, 
when in reality it’s the FCC who has done nothing. the FAA sponsored extensive 
engineering tests that demonstrate the interference is a concern, and they 
notified all the parties well in advance. The fCC et al chose to do no research 
of their own, and are basing all their assumptions on operation in other 
countries, which even you must admit can’t really be congruent with the US.

-mel via cell

On Jan 18, 2022, at 2:01 PM, sro...@ronan-online.com wrote:

 The thing is aviation DOESN’T own this spectrum, they just assumed it would 
always be unused. And they failed to mention it would be a problem during the 
last 5 years of discussion regarding the use of this spectrum.

Shane

On Jan 18, 2022, at 4:25 PM, Mel Beckman  wrote:



Michael,


Here’s a recent PCmag editorial on the subject, and it seems like many people 
want to put Internet speed above airline safety:


https://www.pcmag.com/news/faa-goes-in-hard-to-kill-mid-band-5g


This issue definitely impacts network operations for 5G providers, so makes 
sense to discuss here.


Here’s a comment from a friend of mine who has been both a network engineer and 
a pilot for United Airlines, posted on the article linked above:


“As a pilot, I can tell you that landing in instrument conditions is by far the 
most critical flight regime possible, during which the radar altimeter reports 
are a matter of life and death. There is no alternative technology, such as 
GPS, with the required accuracy and reliability, to provide approach guidance 
down to the runway in zero-zero weather, which is what the radar altimeter does.


The collective tech industry needs to admit that it made a huge blunder when it 
urged the FCC’s clueless Ajit Pai to “blow off” the clearly demonstrated FAA 
spectrum conflict. Sorry, passengers, but if you look out your window, you’ll 
see that aviation owns this spectrum and is entitled to interference-free 
operation. Replacing all radar altimeters isn’t going to happen in time for 5G 
anyway — it took more than ten years just to deploy anti-collision technology. 
So do what you should have done from the beginning: follow the FCC rules of 
non-interference to existing users, who have clear priority in this case.”


I tend to agree with him, and it looks like the 5G providers and FAA agreed 
last week to put some buffer safety zones around runway approaches at 50 major 
airports:


https://www.cnet.com/news/faa-lists-50-airports-getting-temporary-buffer-zones-blocking-new-5g-signals/


-mel

On Jan 18, 2022, at 12:33 PM, Michael Thomas  wrote:


I really don't know anything about it. It seems really late to be having this 
fight now, right?

Mike

Re: What do you think about this airline vs 5G brouhaha?

[Mel Beckman]

Shane,

Incorrect. Owning spectrum also includes the right to interference-free 
operation. And you imply that the FAA and airline industry has done nothing, 
when in reality it’s the FCC who has done nothing. the FAA sponsored extensive 
engineering tests that demonstrate the interference is a concern, and they 
notified all the parties well in advance. The fCC et al chose to do no research 
of their own, and are basing all their assumptions on operation in other 
countries, which even you must admit can’t really be congruent with the US.

-mel via cell

On Jan 18, 2022, at 2:01 PM, sro...@ronan-online.com wrote:

 The thing is aviation DOESN’T own this spectrum, they just assumed it would 
always be unused. And they failed to mention it would be a problem during the 
last 5 years of discussion regarding the use of this spectrum.

Shane

On Jan 18, 2022, at 4:25 PM, Mel Beckman  wrote:



Michael,


Here’s a recent PCmag editorial on the subject, and it seems like many people 
want to put Internet speed above airline safety:


https://www.pcmag.com/news/faa-goes-in-hard-to-kill-mid-band-5g


This issue definitely impacts network operations for 5G providers, so makes 
sense to discuss here.


Here’s a comment from a friend of mine who has been both a network engineer and 
a pilot for United Airlines, posted on the article linked above:


“As a pilot, I can tell you that landing in instrument conditions is by far the 
most critical flight regime possible, during which the radar altimeter reports 
are a matter of life and death. There is no alternative technology, such as 
GPS, with the required accuracy and reliability, to provide approach guidance 
down to the runway in zero-zero weather, which is what the radar altimeter does.


The collective tech industry needs to admit that it made a huge blunder when it 
urged the FCC’s clueless Ajit Pai to “blow off” the clearly demonstrated FAA 
spectrum conflict. Sorry, passengers, but if you look out your window, you’ll 
see that aviation owns this spectrum and is entitled to interference-free 
operation. Replacing all radar altimeters isn’t going to happen in time for 5G 
anyway — it took more than ten years just to deploy anti-collision technology. 
So do what you should have done from the beginning: follow the FCC rules of 
non-interference to existing users, who have clear priority in this case.”


I tend to agree with him, and it looks like the 5G providers and FAA agreed 
last week to put some buffer safety zones around runway approaches at 50 major 
airports:


https://www.cnet.com/news/faa-lists-50-airports-getting-temporary-buffer-zones-blocking-new-5g-signals/


-mel

On Jan 18, 2022, at 12:33 PM, Michael Thomas  wrote:


I really don't know anything about it. It seems really late to be having this 
fight now, right?

Mike

Re: What do you think about this airline vs 5G brouhaha?

[sronan]

The thing is aviation DOESN’T own this spectrum, they just assumed it would 
always be unused. And they failed to mention it would be a problem during the 
last 5 years of discussion regarding the use of this spectrum.

Shane

> On Jan 18, 2022, at 4:25 PM, Mel Beckman  wrote:
> 
> 
> Michael,
> 
> Here’s a recent PCmag editorial on the subject, and it seems like many people 
> want to put Internet speed above airline safety:
> 
> https://www.pcmag.com/news/faa-goes-in-hard-to-kill-mid-band-5g
> 
> This issue definitely impacts network operations for 5G providers, so makes 
> sense to discuss here.
> 
> Here’s a comment from a friend of mine who has been both a network engineer 
> and a pilot for United Airlines, posted on the article linked above:
> 
> “As a pilot, I can tell you that landing in instrument conditions is by far 
> the most critical flight regime possible, during which the radar altimeter 
> reports are a matter of life and death. There is no alternative technology, 
> such as GPS, with the required accuracy and reliability, to provide approach 
> guidance down to the runway in zero-zero weather, which is what the radar 
> altimeter does. 
> 
> The collective tech industry needs to admit that it made a huge blunder when 
> it urged the FCC’s clueless Ajit Pai to “blow off” the clearly demonstrated 
> FAA spectrum conflict. Sorry, passengers, but if you look out your window, 
> you’ll see that aviation owns this spectrum and is entitled to 
> interference-free operation. Replacing all radar altimeters isn’t going to 
> happen in time for 5G anyway — it took more than ten years just to deploy 
> anti-collision technology. So do what you should have done from the 
> beginning: follow the FCC rules of non-interference to existing users, who 
> have clear priority in this case.”
> 
> I tend to agree with him, and it looks like the 5G providers and FAA agreed 
> last week to put some buffer safety zones around runway approaches at 50 
> major airports:
> 
> https://www.cnet.com/news/faa-lists-50-airports-getting-temporary-buffer-zones-blocking-new-5g-signals/
> 
> 
> -mel 
> 
>>> On Jan 18, 2022, at 12:33 PM, Michael Thomas  wrote:
>>> 
>> 
>> I really don't know anything about it. It seems really late to be having 
>> this fight now, right?
>> 
>> Mike
>> 

Re: What do you think about this airline vs 5G brouhaha?

[Michael Thomas]

On 1/18/22 1:47 PM, Brandon Martin wrote:

On 01/18/2022 16:34, Michael Thomas wrote:
Is this the band that has really really short range for 5G? If so, it 
doesn't seem like a very big deal to give them the airspace on 
approaches. I mean, if you live under a flight path by the airport, 
not getting fast 5G is hardly your biggest problem.


This is the C-band spectrum near 4GHz.  The super short-range (or, 
rather, highly direction and subject to attenuation by almost 
anything) that you're probably thinking of is likely the UWB mmWave 
band up at ~30GHz.


C-band has moderate structure penetration and limited foliage 
penetration.  With line of sight and at the power levels the carriers 
would consider running, several miles of usable range would be 
unsurprising, though I suspect many typical deployments would have 
design cells smaller than that while using existing "4g" (and newly 
opened ex-TV broadcast space) low- and mid-band frequencies for wider 
area coverage at reduced speeds. Interference considerations, 
especially high above the horizon (planes...) would be present for 
potentially dozens of miles away.


An article I read said that other countries are accommodating them. What 
are they doing different?


Mike

Re: What do you think about this airline vs 5G brouhaha?

[Mike Hammett]

Fearmongering. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Michael Thomas"  
To: nanog@nanog.org 
Sent: Tuesday, January 18, 2022 2:29:53 PM 
Subject: What do you think about this airline vs 5G brouhaha? 


I really don't know anything about it. It seems really late to be having 
this fight now, right? 

Mike 

Re: What do you think about this airline vs 5G brouhaha?

[Mel Beckman]

Brandon,

Bo, it’s the radar altimeter, not the barometric altimeter. This is a radar 
distance measurement device for determine the precise height above the ground,  
critical for low-visibility approaches. 

Where frequency interference is concerned, under FCC rules the existing users 
have priority, and are entitled to interference-free operation. 

-mel via cell

> On Jan 18, 2022, at 1:43 PM, Brandon Martin  wrote:
> 
> On 01/18/2022 15:29, Michael Thomas wrote:
>> I really don't know anything about it. It seems really late to be having 
>> this fight now, right?
> 
> The issue seems to be old aviation equipment that has poor receiver 
> selectivity on its radio (not radar) altimeter.  This is, apparently, a 
> secondary, but still very important, instrument for instrument approaches 
> upon landing.
> 
> This older equipment can be subject to meaningful interference by signals as 
> much as 500MHz outside the actual assigned radio altimeter band limit.  Note 
> that the radio altimeter band is only about 500MHz wide itself, so even a 
> naive single-conversion receiver could/should have better selectivity that 
> this.  The reason for this poor selectivity seems to simply be that, at the 
> time, there was nothing else using the RF spectrum nearby, so they could get 
> away with it, and it made the receiver somewhat simpler.
> 
> The system apparently also responds poorly to both narrowband and wideband 
> jammers i.e. it does not employ what we'd consider robust, modern 
> error-correction or coding systems or even digital error checking techniques.
> 
> Both of these are basically issues with how old the system is and how old a 
> large amount of deployed equipment using it is.  The former is probably hard 
> to fix in a backwards compatible way, but the latter is mostly a matter of 
> upgrading your instruments more than once every 25 years which, for planes 
> that are actually routinely making use of this system (largely commercial and 
> charter operators), doesn't really seem like that big of an ask.
> 
> I think the issue is that the FCC did some rulemaking assuming that existing 
> service users were being reasonable with their equipment design, then a giant 
> game of chicken got started, and nobody blinked in time for anything to get 
> done until a collision was imminent.
> 
> The C-band spectrum at issue here has become very valuable, both economically 
> and from a public usage perspective, for mid- and short-range wireless 
> communications.  The FCC allocated some of it based on "reasonable" 
> expectations of existing users and provided an ample (arguably rather large) 
> guard band between services.
> 
> In the end, I'd say that aviation folks are in the wrong, here, but they also 
> have a lot of history to contend with and a large install base of gear that, 
> whether it "should" or not, apparently does need to be upgraded to prevent 
> detrimental interference to an important flight safety and operations 
> facility.  A pause in deployment seems reasonable in that light, though it 
> would have been nice if folks could have gotten this resolved sooner.
> 
> --
> Brandon Martin

Re: What do you think about this airline vs 5G brouhaha?

[Brandon Martin]

On 01/18/2022 16:34, Michael Thomas wrote:
Is this the band that has really really short range for 5G? If so, it 
doesn't seem like a very big deal to give them the airspace on 
approaches. I mean, if you live under a flight path by the airport, not 
getting fast 5G is hardly your biggest problem.


This is the C-band spectrum near 4GHz.  The super short-range (or, 
rather, highly direction and subject to attenuation by almost anything) 
that you're probably thinking of is likely the UWB mmWave band up at ~30GHz.


C-band has moderate structure penetration and limited foliage 
penetration.  With line of sight and at the power levels the carriers 
would consider running, several miles of usable range would be 
unsurprising, though I suspect many typical deployments would have 
design cells smaller than that while using existing "4g" (and newly 
opened ex-TV broadcast space) low- and mid-band frequencies for wider 
area coverage at reduced speeds.  Interference considerations, 
especially high above the horizon (planes...) would be present for 
potentially dozens of miles away.


--
Brandon Martin

Re: What do you think about this airline vs 5G brouhaha?

[Brandon Martin]

On 01/18/2022 15:29, Michael Thomas wrote:
I really don't know anything about it. It seems really late to be having 
this fight now, right?


The issue seems to be old aviation equipment that has poor receiver 
selectivity on its radio (not radar) altimeter.  This is, apparently, a 
secondary, but still very important, instrument for instrument 
approaches upon landing.


This older equipment can be subject to meaningful interference by 
signals as much as 500MHz outside the actual assigned radio altimeter 
band limit.  Note that the radio altimeter band is only about 500MHz 
wide itself, so even a naive single-conversion receiver could/should 
have better selectivity that this.  The reason for this poor selectivity 
seems to simply be that, at the time, there was nothing else using the 
RF spectrum nearby, so they could get away with it, and it made the 
receiver somewhat simpler.


The system apparently also responds poorly to both narrowband and 
wideband jammers i.e. it does not employ what we'd consider robust, 
modern error-correction or coding systems or even digital error checking 
techniques.


Both of these are basically issues with how old the system is and how 
old a large amount of deployed equipment using it is.  The former is 
probably hard to fix in a backwards compatible way, but the latter is 
mostly a matter of upgrading your instruments more than once every 25 
years which, for planes that are actually routinely making use of this 
system (largely commercial and charter operators), doesn't really seem 
like that big of an ask.


I think the issue is that the FCC did some rulemaking assuming that 
existing service users were being reasonable with their equipment 
design, then a giant game of chicken got started, and nobody blinked in 
time for anything to get done until a collision was imminent.


The C-band spectrum at issue here has become very valuable, both 
economically and from a public usage perspective, for mid- and 
short-range wireless communications.  The FCC allocated some of it based 
on "reasonable" expectations of existing users and provided an ample 
(arguably rather large) guard band between services.


In the end, I'd say that aviation folks are in the wrong, here, but they 
also have a lot of history to contend with and a large install base of 
gear that, whether it "should" or not, apparently does need to be 
upgraded to prevent detrimental interference to an important flight 
safety and operations facility.  A pause in deployment seems reasonable 
in that light, though it would have been nice if folks could have gotten 
this resolved sooner.


--
Brandon Martin

Re: What do you think about this airline vs 5G brouhaha?

[Michael Thomas]

On 1/18/22 1:25 PM, Mel Beckman wrote:


Michael,


Here’s a recent PCmag editorial on the subject, and it seems like many 
people want to put Internet speed above airline safety:



https://www.pcmag.com/news/faa-goes-in-hard-to-kill-mid-band-5g 




This issue definitely impacts network operations for 5G providers, so 
makes sense to discuss here.



Here’s a comment from a friend of mine who has been both a network 
engineer and a pilot for United Airlines, posted on the article linked 
above:



/“As a pilot, I can tell you that landing in instrument conditions is 
by far the most critical flight regime possible, during which the 
radar altimeter reports are a matter of life and death. There is no 
alternative technology, such as GPS, with the required accuracy and 
reliability, to provide approach guidance down to the runway in 
zero-zero weather, which is what the radar altimeter does. /


/
/

/The collective tech industry needs to admit that it made a huge 
blunder when it urged the FCC’s clueless Ajit Pai to “blow off” the 
clearly demonstrated FAA spectrum conflict. Sorry, passengers, but if 
you look out your window, you’ll see that aviation owns this spectrum 
and is entitled to interference-free operation. Replacing all radar 
altimeters isn’t going to happen in time for 5G anyway — it took more 
than ten years just to deploy anti-collision technology. So do what 
you should have done from the beginning: follow the FCC rules of 
non-interference to existing users, who have clear priority in this 
case.”/



I tend to agree with him, and it looks like the 5G providers and FAA 
agreed last week to put some buffer safety zones around runway 
approaches at 50 major airports:




Is this the band that has really really short range for 5G? If so, it 
doesn't seem like a very big deal to give them the airspace on 
approaches. I mean, if you live under a flight path by the airport, not 
getting fast 5G is hardly your biggest problem.


Mike

Re: What do you think about this airline vs 5G brouhaha?

[Mel Beckman]

Michael,


Here’s a recent PCmag editorial on the subject, and it seems like many people 
want to put Internet speed above airline safety:


https://www.pcmag.com/news/faa-goes-in-hard-to-kill-mid-band-5g


This issue definitely impacts network operations for 5G providers, so makes 
sense to discuss here.


Here’s a comment from a friend of mine who has been both a network engineer and 
a pilot for United Airlines, posted on the article linked above:


“As a pilot, I can tell you that landing in instrument conditions is by far the 
most critical flight regime possible, during which the radar altimeter reports 
are a matter of life and death. There is no alternative technology, such as 
GPS, with the required accuracy and reliability, to provide approach guidance 
down to the runway in zero-zero weather, which is what the radar altimeter does.


The collective tech industry needs to admit that it made a huge blunder when it 
urged the FCC’s clueless Ajit Pai to “blow off” the clearly demonstrated FAA 
spectrum conflict. Sorry, passengers, but if you look out your window, you’ll 
see that aviation owns this spectrum and is entitled to interference-free 
operation. Replacing all radar altimeters isn’t going to happen in time for 5G 
anyway — it took more than ten years just to deploy anti-collision technology. 
So do what you should have done from the beginning: follow the FCC rules of 
non-interference to existing users, who have clear priority in this case.”


I tend to agree with him, and it looks like the 5G providers and FAA agreed 
last week to put some buffer safety zones around runway approaches at 50 major 
airports:


https://www.cnet.com/news/faa-lists-50-airports-getting-temporary-buffer-zones-blocking-new-5g-signals/


-mel

On Jan 18, 2022, at 12:33 PM, Michael Thomas  wrote:


I really don't know anything about it. It seems really late to be having this 
fight now, right?

Mike

Re: home router battery backup

[Joe Maimon]

Mark Tinka wrote:



On 1/18/22 18:15, Joe Maimon wrote:



Now how about some programming available so you can decide what 
thresholds and conditions remote start your genny which powers the 
rectifier which substitutes|augments the solar array?


Any half decent battery inverters will be able to adequately support 
this, out the box.


Mark.




The inverter in question is the one being utilized in conjunction with 
the powerwall, ats, solar array. All nicely done and reliable and wired 
in already and with proper capacity.


Being able to call for and get more DC power on demand would make this a 
true uninterruptible solution.


Running a gen to support the battery means the gen size does not need to 
correlate at all with the peaks and surges of demand and can run at 
maximum efficiency and we can avoid unbalanced leg problems and other 
voltage variation issues that can happen with portable gens.


Programming comes into play for automated monthly testing, capacity 
prediction, even spot costing of utility power. Between the grid, the 
solar array, time of day, season, weather, battery level, generator 
input, load characteristics, outage duration, grid costs/stresses there 
can be a lot of factors that might need a bit more balancing and 
programming than you might typically expect available from any half 
decent battery inverter, but might find a nice place in a truly fully 
integrated home UPS solution.


Integrate it enough and perhaps the gen/rectifier components would even 
fit into typical residential facilities spaces and this sort of setup 
could be all the more typical and standard.


Joe

Re: home router battery backup

[Jordan Hazen]

On Thu, Jan 13, 2022 at 10:38:53AM -0500, Jay wrote:
> Greetings,
> I am a home user.  Much of my home has been rewired to run off of 
> 12-volts D.C. from a large 1200 Amp/Hour LiFePO4 battery bank that is 
> recharged using Solar.  All my lighting, ceiling fans, water pump, Ham 
> radio gear, weather alert radio, USB charging stations, alarm system, 
> security cameras and DVR, my wife's CPAP machine, 40-inch flat screen TV, 
> ROKU streaming device, etc. all now run off 12 VDC.

What was required to run your 40" television on 12V?  Did you
replace its internal PSU, or just feed it a boosted DC voltage?

(For anyone unaware, most, but not all, switchmode supplies are
happy running from DC in the same general range as their marked AC
voltage.  Some are polarity-sensitive, and active PFC occasionally
causes trouble.  Also, small commodity MSW inverters can be easily
changed into 12V -> 160V or 12V -> 300V DC/DC boost converters by
disabling and bypassing their final chopper stage, at considerable
efficiency gain.  Just don't run the boosted DC through switches,
relays, or breakers meant for AC - these will quickly fail in such
use due to arcing and/or welded contacts! Fuse the DC-input side.)

I've gone down a similar path, standardizing on Anderson Powerpoles
for 12V distribution, but limited my scope to 24/7 loads, phones,
telecom/network/radio equipment, other low-wattage electronics, and
a small fraction of (LED) lighting, to avoid extending heavy-gauge
copper all over the house.  One motivation was to reduce the impact
if our main household inverter were to fail while operating off
grid.  Another was let that unit be turned off at night with little
inconvenience, or put into "search" mode where it switches on only
when detecting that an intermittent load wants to run, such as the
well pump or refrigerator.  Newer fridges with electronic controls
unfortunately don't like to operate in this mode, but have gained
enough efficiency to more than make up for standby inverter loss.

My 12V bank is still AGM lead-acid, but doesn't see frequent
discharge, usually floating from solar during the day and from a
central AC supply at night, providing the grid is up.  24V is
available too from the garage PV solar system batteries, though
only in two rooms.  This runs a 24V->12V DC/DC to power the 12V bus
(normally current-limited by PWM signal from the PV charge
controllers, based on available sun.  This makes better use of
limited PV power in morning & evening hours than the large Outback
Power hybrid inverter would, with its 40W standby loss.

To circle back somewhat to the original topic, Outback was acquired
by Alpha Power several years ago, but I haven't yet noticed much
integration between their traditional telco/MSO product line and
the Outback equipment.

> High consumption devices like stove, refrigerators, air
> conditioners, furnace, still run on AC but get *much* of their
> power from a 5kw Grid-Tied Solar array (Enphase IQ7
> microinverters) which I hope to soon add a battery backup to. 
> There is also a whole-house 4kw backup generator.  This is what
> is known as a "Hybrid" home :)

I installed a 120V-only protected loads subpanel next to our main
panel and moved most circuits over, to take advantage of the
Outback hybrid inverter's integral automatic transfer switch and
use it as an (almost) whole-house UPS.  240V circuits drop, but
little else does.  Most importantly, refrigeration and our
well-water pump (1hp, ~1200W draw, too large for practical DC
conversion) can remain powered indefinitely, whether anyone is home
or not.  Central HVAC is not backed up, but we can run a couple of
window units.

Due to its use of heavy 60A relays, the transfer time of this type
of inverter is a bit slow by UPS standards, roughly 30ms, but no
computers or other AC loads seem to mind.  Important gear is all on
12V anyway.  There is an alternate, zero-transfer-time mode of
operation where the inverter is kept constantly running in
phase-lock to incoming power, and steps in even before the
isolation relay fully opens.  This comes at the cost of 20+W of
additional 24/7 load, and may not entirely meet the letter of
UL1741 or IEEE1547 anti-backfeed requirements, so I opted against.

> ALL of my servers, workstations, routers/hubs, WiFi, are also converted 
> to run on 12VDC from this battery/solar plant.  In many cases it is just a 
> matter of adding a DC-DC buck/booster regulator that can be purchased on 
> Amazon for ten bucks, or so.  These generally take 8-40 volts input and 
> will deliver whatever voltage output that you desire.  Both my DSL and 
> FTTH are powered this way.

My sister-in-law bought an off-grid home whose previous owner had
wired every room for both 12VDC and 120VAC.  Lighting, fans, etc. 
were nearly all 12V.  This was nice at first, especially the old
and noisy MSW inverter, but did complicate their eventual upgrade
to a larger system and its required 48V battery bank.  They
required a 

Re: Long hops on international paths

[William Herrin]

On Tue, Jan 18, 2022 at 6:49 AM PAUL R BARFORD  wrote:
> So, the question is what is the cost/benefit to providers to
> configure/maintain routes (that include long MPLS tunnels)
> that tend to concentrate international connectivity at a
> relatively small number of routers?

Most likely that's not what's happening. None of your traces showed
traffic going to Chicago and then doubling back. I can't say with
certainty what this means but my educated guess is this:

Chicago is a major peering point for the networks in question, so
packets headed more or less that direction tend to hop over there
instead of somewhere else. Having crossed over, they enter the MPLS
system which is opaque to traceroute, so they're not seen again until
they exit MPLS. Traffic originating closer to the final destination
goes to a scattering of other MPLS entry points instead, so Chicago
looks outsized in the data. The actual traffic flow, opaque inside
MPLS, goes through the nodes you'd expect, close to the cable
landings.

So it's not a question of whether the traffic has an international
destination, it's a question of whether that backbone is in the path
to the destination (international or not). Rephrase your question as:
is there a cost/benefit to providers having a small number of very
large peering points accepting traffic into their networks in addition
to the myriad small ones.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

need commercial connection in elkton, fl

[james jones]

Anyone have coverage on county road 305 in elkton, fl 32033.If so,
please contact me off list.

-James

Re: home router battery backup

[Michael Thomas]

On 1/18/22 12:24 PM, Mark Tinka wrote:



On 1/18/22 18:15, Joe Maimon wrote:



Now how about some programming available so you can decide what 
thresholds and conditions remote start your genny which powers the 
rectifier which substitutes|augments the solar array?


Any half decent battery inverters will be able to adequately support 
this, out the box.


I have a SolarEdge inverter and they are still working on the software. 
I don't know if that's true across their product line, but I would think 
that the software would be pretty portable.


Mike

What do you think about this airline vs 5G brouhaha?

[Michael Thomas]

I really don't know anything about it. It seems really late to be having 
this fight now, right?


Mike

Re: home router battery backup

[Jordan Hazen]

On Tue, Jan 18, 2022 at 05:11:57PM +0200, Mark Tinka wrote:
> 
> I don't use the Tesla Powerwall, but Li-Ion is generally the same 
> regardless of who packages it. The difference will be what the OEM 
> decides to set the low-voltage cut-off to on the inverter and/or BMS.

Yes, but separate from their absolute low-voltage cutoff meant to
protect battery cells, these hybrid storage products include a
user-adjustable reserve setpoint, meant to balance their backup
role with grid support and peak-shaving.

Owners of home-scale PV+battery systems often sign up for
time-of-use utility tariffs, where per-kWh rates are high during
peak periods (day and evening), but very low at night.  With a
large enough system at full charge, such homes can then run
autonomously for several hours after sunset, covering most or all
of the peak-demand period, before switching back to grid power, and
optionally recharging at night when rates and demand are low (if
local solar production alone isn't enough replenishment).

Of course, letting the battery discharge all the way to its 0%
safety limit in its daily demand shifting role, besides prematurely
aging the cells, would leave the owner without backup were an
outage to strike at a bad time, in late afternoon or evening.

With the utility paying for and managing distributed batteries
itself, though, they'd want to derive the greatest possible return
on their investment, and so probably tend to set that reserve-limit
very low.

Some utilities have been experimenting with using these storage
systems as part of demand-side management / load shedding, where
during peak periods they can signal for buildings capable of
operating from battery power to start doing do for a set period of
time.  With enough aggregate storage available, this could avoid
having to fire up an expensive-to-operate natural gas peaker plant.

The battery system owner would receive bill credits, lower rates,
or other incentives in exchange for allowing this, similar to how
some data centers and other industrial building will be compensated
for proactively switching to generator power when asked to during a
high-demand period.

Is anyone aware of data centers yet leveraging battery storage for
a similar purpose?  It would make zero economic sense with
traditional lead-acid storage, of course, due to such batteries'
limited cycle life and intolerance of deep discharge.

> I'm not sure how much the owner can configure a Tesla Powerwall, but 
> with other installations, you can decide when your battery kicks in to 
> run loads, or when it hands back to the grid or generator. This assumes 
> evening time, when solar irradiation is unavailable, of course, as that 
> is generally the preferred source of energy.

Uilities are becoming increasingly hostile to solar net-metering,
where PV system owners are credited for excess energy supplied to
the grid during peak sun hours, then allowed to "draw this back" at
parity after sunset, using the grid as a sort of virtual battery. 
They argue that such use incurs uncompensated costs (see "duck
curve"), and have successfully lobbied for tariff changes in some
areas to limit or end the practice.  Other locales have never had
net-metering.  On-site storage can be a good alternative to net
metering where it's unavailable, and is probably more beneficial to
grid stability.

> I've heard that Tesla will monitor the weather in your area to 
> "pre-charge" the Powerwall to account for possible power disruptions. 
> While I find that rather invasive, it's a cool feature for folk who 
> "don't want to know". Then again, I also hear that Tesla will limit or 
> withhold support and/or warranty if you do not connect your Powerwall to 
> the Internet for them to "manage". The downside I hear, with that, is 
> that they can remotely adjust SoH (state of health) thresholds to 
> lengthen battery life in order to meet warranty promises. Not sure how 
> true that is, but I've heard it a lot.

They apparently do this with their vehicles as well.  Claimed
0%-100% figures are mapped onto a somewhat narower, but hidden
true-SoC range at first, which is silently broadened over time to
compensate for cell aging.  Understandable, but I'm also uneasy at
such information-hiding.

> In terms of "reserve" capacity, Li-Ion can go much deeper than Lead 
> Acid. Some inverters are setup to disconnect the battery anywhere 
> between 3% - 20% SoC, depending on the OEM. For LFP chemistries, the BMS 
> will usually turn the pack off at 2.50V, while for NMC, that will be 
> around 2.75V. But different battery OEM's may be more or less aggressive 
> with their BMS's, depending on who you choose to buy from.

LFP (LiFePO4), with its longer cycle life may be the best
currently- available chemistry for fixed storage, where its lower
gravimetric & volumetric energy density (vs NMC) doesn't matter so
much.  NMC has economies of scale going for it, though, along with
what's likely to be an ever-increasing supply of 

Re: home router battery backup

[Mark Tinka]

On 1/18/22 18:15, Joe Maimon wrote:



Now how about some programming available so you can decide what 
thresholds and conditions remote start your genny which powers the 
rectifier which substitutes|augments the solar array?


Any half decent battery inverters will be able to adequately support 
this, out the box.


Mark.

Re: home router battery backup

[Grant Taylor via NANOG]

On 1/17/22 3:39 PM, Jordan wrote:
One of these, the one originally used for DSL, would always go down 
for both voice and data when the SLC lost power-- no DC, no dialtone, 
no DSL, while the other two remained up.  Despite several claims of 
a resolution, this was never properly fixed


I never had that specific problem.  But I occasionally had problems with 
repairs on B1s, a.k.a. "Life saving service" lines.  I had a couple of 
times that I had to threaten going to the Public Utilities Commission in 
the state for the ILEC's failure to repair a line.


I'll give the first failed repair gratis.  I make a comment when 
scheduling the second repair that they really need to fix it as I'd hate 
to have to report the failure to the PUC.  The third repair was more 
along the lines of "you fix this (now / on my time frame) or I am 
reporting this with full details to the PUC".  Thankfully I only had to 
report things to the PUC one time.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Undersea cable damages in the Atlantic?

[Sean Donelan]

On Tue, 18 Jan 2022, Andy Ringsmuth wrote:

Hmmm…

Multiple sub-sea cable problems referencing Europe and the US east coast…

Putin testing the waters for connectivity disruptions ahead of a Ukraine 
invasion? Where the US and NATO are the thorn in his side?


Naw, that's Svalbard, Norway cable damage.  That cable just happens to 
connect to the satellite control station for polar orbit satellites.



https://www.sysselmesteren.no/contentassets/8e497b11f18146029a022462c8dc09ca/pressemelding-fra-space-norway.pdf

Re: Undersea cable damages in the Atlantic?

[Andy Ringsmuth]

> On Jan 18, 2022, at 11:08 AM, Mukund Sivaraman  wrote:
> 
> We received the following email today from our upstream (in India):
> 
>> Our transit traffic partners have reported multiple sub-sea cable
>> damages on the Atlantic route towards Europe and US east coast. Users
>> might face additional latency and occasional packet loss towards these
>> destinations.
>> 
>> Our partners are working with relevant authorities and cable sea
>> companies for restoration and will take few days to address it. We
>> will inform as soon as this is resolved. Inconvenience caused is
>> highly regretted.
> 
> I've read about cable cuts due to the Tonga volcanic eruption, but the
> above as "multiple cable damages" is mentioned as in the Atlantic. Does
> anyone know more about this? A news search for "cable cuts" didn't bring
> up anything aside from the Tonga story.
> 
>   Mukund

Hmmm…

Multiple sub-sea cable problems referencing Europe and the US east coast…

Putin testing the waters for connectivity disruptions ahead of a Ukraine 
invasion? Where the US and NATO are the thorn in his side?



-Andy

Re: Undersea cable damages in the Atlantic?

[Christopher Munz-Michielin]

Our Singapore routes currently go through France, heh.

Start: 2022-01-18T13:32:07-0500
HOST: bom-h01.int.controld.com    Loss%   Snt   Last   Avg  Best Wrst StDev
  1.|-- 103.13.115.1   0.0%    10    0.5   2.1   0.3 15.5   4.7
  2.|-- 103.149.113.69 0.0%    10    2.1   2.0   1.9 2.1   0.1
  3.|-- 203.199.133.125    0.0%    10    7.0   4.6   3.2 10.7   2.4
  4.|-- 172.28.176.254 0.0%    10    4.0   3.5   3.2 4.0   0.2
  5.|-- ix-ae-1-100.tcore2.mlv-mu  0.0%    10    3.3   3.6   3.3 4.8   0.4
  6.|-- if-ae-16-2.tcore1.svw-sin 80.0%    10  180.1 180.1 180.1 
180.1   0.0
  7.|-- if-ae-31-6.tcore1.wyn-mar 10.0%    10  179.9 180.2 179.9 
181.2   0.4
  8.|-- if-ae-2-3.tcore2.wyn-mars 40.0%    10  179.7 180.2 179.5 
181.7   0.8
  9.|-- if-ae-7-2.tcore2.fnm-fran 10.0%    10  180.3 180.3 179.8 
181.2   0.5
 10.|-- if-ae-4-2.tcore1.fr0-fran  0.0%    10  179.7 179.8 179.7 
180.0   0.1
 11.|-- 195.219.50.202 0.0%    10  309.0 310.4 308.8 
315.9   2.9
 12.|-- HundredGE0-5-0-0.br03.sin  0.0%    10  306.8 307.2 305.4 
314.3   2.7
 13.|-- HundredGE0-5-0-0.br03.sin  0.0%    10  305.4 307.4 305.3 
313.7   2.6
 14.|-- metro.tenGigE0-6-0-20.10.  0.0%    10  309.1 308.4 305.9 
314.5   2.8
 15.|-- 37.120.220.219 0.0%    10  318.9 328.0 314.7 376.2  
18.6
 16.|-- 84.247.49.130  0.0%    10  325.9 324.7 318.9 
334.4   4.8
 17.|-- 84.247.49.100  0.0%    10  317.5 311.4 309.3 
318.0   3.4


On 2022-01-18 10:17 a.m., Anurag Bhatia wrote:
Are you sure it was about poor routing to Singapore and not poor 
routing to networks in EU?


The reason I ask is that a majority of connectivity has been lost to 
EU and EU > India is mostly via US > Singapore now.
I see high latency on this route for that reason but so far haven't 
seen packet loss or routing issues with Singapore.





Thanks.

On Tue, Jan 18, 2022 at 10:46 PM Christopher Munz-Michielin 
 wrote:


For what it's worth we have a provider in India for an anycast
network
who gave us a similar answer when we ticketed them about poor
routing to
Singapore.

Chris

On 2022-01-18 9:08 a.m., Mukund Sivaraman wrote:
> We received the following email today from our upstream (in India):
>
>> Our transit traffic partners have reported multiple sub-sea cable
>> damages on the Atlantic route towards Europe and US east coast.
Users
>> might face additional latency and occasional packet loss
towards these
>> destinations.
>>
>> Our partners are working with relevant authorities and cable sea
>> companies for restoration and will take few days to address it. We
>> will inform as soon as this is resolved. Inconvenience caused is
>> highly regretted.
> I've read about cable cuts due to the Tonga volcanic eruption,
but the
> above as "multiple cable damages" is mentioned as in the
Atlantic. Does
> anyone know more about this? A news search for "cable cuts"
didn't bring
> up anything aside from the Tonga story.
>
>               Mukund



--
Anurag Bhatia
anuragbhatia.com 

Re: Undersea cable damages in the Atlantic?

[Anurag Bhatia]

Are you sure it was about poor routing to Singapore and not poor routing to
networks in EU?

The reason I ask is that a majority of connectivity has been lost to EU and
EU > India is mostly via US > Singapore now.
I see high latency on this route for that reason but so far haven't seen
packet loss or routing issues with Singapore.




Thanks.

On Tue, Jan 18, 2022 at 10:46 PM Christopher Munz-Michielin <
christop...@ve7alb.ca> wrote:

> For what it's worth we have a provider in India for an anycast network
> who gave us a similar answer when we ticketed them about poor routing to
> Singapore.
>
> Chris
>
> On 2022-01-18 9:08 a.m., Mukund Sivaraman wrote:
> > We received the following email today from our upstream (in India):
> >
> >> Our transit traffic partners have reported multiple sub-sea cable
> >> damages on the Atlantic route towards Europe and US east coast. Users
> >> might face additional latency and occasional packet loss towards these
> >> destinations.
> >>
> >> Our partners are working with relevant authorities and cable sea
> >> companies for restoration and will take few days to address it. We
> >> will inform as soon as this is resolved. Inconvenience caused is
> >> highly regretted.
> > I've read about cable cuts due to the Tonga volcanic eruption, but the
> > above as "multiple cable damages" is mentioned as in the Atlantic. Does
> > anyone know more about this? A news search for "cable cuts" didn't bring
> > up anything aside from the Tonga story.
> >
> >   Mukund
>


-- 
Anurag Bhatia
anuragbhatia.com

Re: Undersea cable damages in the Atlantic?

[Rob Evans]

Also FWIW, we've been informed of outages on TGN-EA (since 15/01/22)
and IMEWE (since 15/10/21), both "away from the Mumbai coast." No ETR
currently available.

Rob

Re: Undersea cable damages in the Atlantic?

[Christopher Munz-Michielin]

For what it's worth we have a provider in India for an anycast network 
who gave us a similar answer when we ticketed them about poor routing to 
Singapore.


Chris

On 2022-01-18 9:08 a.m., Mukund Sivaraman wrote:

We received the following email today from our upstream (in India):


Our transit traffic partners have reported multiple sub-sea cable
damages on the Atlantic route towards Europe and US east coast. Users
might face additional latency and occasional packet loss towards these
destinations.

Our partners are working with relevant authorities and cable sea
companies for restoration and will take few days to address it. We
will inform as soon as this is resolved. Inconvenience caused is
highly regretted.

I've read about cable cuts due to the Tonga volcanic eruption, but the
above as "multiple cable damages" is mentioned as in the Atlantic. Does
anyone know more about this? A news search for "cable cuts" didn't bring
up anything aside from the Tonga story.

Mukund

Undersea cable damages in the Atlantic?

[Mukund Sivaraman]

We received the following email today from our upstream (in India):

> Our transit traffic partners have reported multiple sub-sea cable
> damages on the Atlantic route towards Europe and US east coast. Users
> might face additional latency and occasional packet loss towards these
> destinations.
>
> Our partners are working with relevant authorities and cable sea
> companies for restoration and will take few days to address it. We
> will inform as soon as this is resolved. Inconvenience caused is
> highly regretted.

I've read about cable cuts due to the Tonga volcanic eruption, but the
above as "multiple cable damages" is mentioned as in the Atlantic. Does
anyone know more about this? A news search for "cable cuts" didn't bring
up anything aside from the Tonga story.

Mukund


signature.asc
Description: PGP signature

Re: home router battery backup

[Joe Maimon]

Mark Tinka wrote:



On 1/18/22 00:26, Jordan wrote:


Wow, that's a nice program.  Do you know what they keep the
"reserve percentage" set to, the proportion of stored energy that
will never be discharged for grid-support, but held back for
island-mode use in case of an outage?


I don't use the Tesla Powerwall, but Li-Ion is generally the same
regardless of who packages it. The difference will be what the OEM
decides to set the low-voltage cut-off to on the inverter and/or BMS.

I'm not sure how much the owner can configure a Tesla Powerwall, but
with other installations, you can decide when your battery kicks in to
run loads, or when it hands back to the grid or generator. This
assumes evening time, when solar irradiation is unavailable, of
course, as that is generally the preferred source of energy.



Now how about some programming available so you can decide what 
thresholds and conditions remote start your genny which powers the 
rectifier which substitutes|augments the solar array?


All those 6500 PS lying about would make awesome rectifiers.

Joe


I've heard that Tesla will monitor the weather in your area to
"pre-charge" the Powerwall to account for possible power disruptions.
While I find that rather invasive, it's a cool feature for folk who
"don't want to know". Then again, I also hear that Tesla will limit or
withhold support and/or warranty if you do not connect your Powerwall
to the Internet for them to "manage". The downside I hear, with that,
is that they can remotely adjust SoH (state of health) thresholds to
lengthen battery life in order to meet warranty promises. Not sure how
true that is, but I've heard it a lot.

In terms of "reserve" capacity, Li-Ion can go much deeper than Lead
Acid. Some inverters are setup to disconnect the battery anywhere
between 3% - 20% SoC, depending on the OEM. For LFP chemistries, the
BMS will usually turn the pack off at 2.50V, while for NMC, that will
be around 2.75V. But different battery OEM's may be more or less
aggressive with their BMS's, depending on who you choose to buy from.

Mark.

Re: SOHO IPv6 switches

[Bjørn Mork]

Brandon Martin  writes:

> The Netgear GS108T is my typical go-to "not a dumb switch".  8 ports
> for about $80.
>
> Make sure you get the v3 if you want most of the modern IPv6 L2
> features (you also get some very limited L3 capabilities). 

Extra bonus with the GS108Tv3, and anything else based on the RTL8380,
is that you can run OpenWrt on it.


Bjørn

Re: SOHO IPv6 switches

[Brandon Martin]

The Netgear GS108T is my typical go-to "not a dumb switch".  8 ports for 
about $80.


Make sure you get the v3 if you want most of the modern IPv6 L2 features 
(you also get some very limited L3 capabilities).  The v2 lacks most of 
them and is still readily available on the market.


--
Brandon Martin

Re: Long hops on international paths

[Nick Hilliard]

PAUL R BARFORD wrote on 18/01/2022 14:48:
So, the question is what is the cost/benefit to providers to 
configure/maintain routes (that include long MPLS tunnels) that tend to 
concentrate international connectivity at a relatively small number of 
routers?


the cost of mpls TE is pretty low: a couple of extra config lines per 
LSP.  The benefit can be substantial in terms of having fine-grained 
control of how packets traverse a network, and allow optimisation of 
specific policy outcomes, e.g. cost / latency / throughput / pktloss / 
qos / etc.


Nick

Re: Long hops on international paths

[Saku Ytti]

On Tue, 18 Jan 2022 at 17:27, Mark Tinka  wrote:
> > https://ytti.github.io/icmp-eo-timestamp/draft-ytti-intarea-icmp-eo-timestamp.html

> I recall you and I chatted about this some 3 or so years ago. Do you
> know if anyone of the (un)usual suspects have implemented?

I've not even submitted it, so that's a no.

-- 
  ++ytti

Re: Long hops on international paths

[PAUL R BARFORD]

Thanks Saku and Michael.

From: Saku Ytti 
Sent: Tuesday, January 18, 2022 9:17 AM
To: Michael Hare 
Cc: PAUL R BARFORD ; Esteban Carisimo 
; nanog@nanog.org ; Fabian 
E. Bustamante 
Subject: Re: Long hops on international paths

On Tue, 18 Jan 2022 at 17:14, Michael Hare  wrote:

> AS3128 runs MPLS and it's probable someone might correct me here, but for a 
> IGP backbone area I think it's common for there to be a full mesh of LSPs via 
> either LDP, RSVP, SR etc.  AS3128 is a small regional and we operate in that 
> way across 60+ nodes.  I don't know if it's common for someone with a global 
> footprint like 1299 to have a contiguous global MPLS backbone, but the point 
> of my reply was to say it's not impossible to think 1299 has a global MPLS 
> mesh between major POPs.

Yes, this is the common case, not an exception.

--
  ++ytti

Re: Long hops on international paths

[Mark Tinka]

On 1/18/22 17:14, Michael Hare via NANOG wrote:

Paul-

You said: "... would decide to configure MPLS paths between Chicago and distant 
international locations ..."

AS3128 runs MPLS and it's probable someone might correct me here, but for a IGP 
backbone area I think it's common for there to be a full mesh of LSPs via 
either LDP, RSVP, SR etc.  AS3128 is a small regional and we operate in that 
way across 60+ nodes.  I don't know if it's common for someone with a global 
footprint like 1299 to have a contiguous global MPLS backbone, but the point of 
my reply was to say it's not impossible to think 1299 has a global MPLS mesh 
between major POPs.


100%.

Mark.

Re: Long hops on international paths

[Mark Tinka]

On 1/18/22 16:28, Saku Ytti wrote:


2) MPLS-TTL expires in transit
2a) generate TTL exceeded and put it back to tunnel, sending it to
egressPE, which is guaranteed to know how to return to sender


This is what we run - our core is BGP-free (LDP), so the traceroute 
value customers see will be the egress PE router.



2nd best is to tunnel, but the
RTT will confuse uneducated, or as it may be, hjghly educated, users.


It is very confusing, even for some educated users.

It's become less of problem, as years of educating users seems to have 
bedded in.



We could implement something like
https://ytti.github.io/icmp-eo-timestamp/draft-ytti-intarea-icmp-eo-timestamp.html
to offer correct forward latencies to P/LSR in 2a scenario.


I recall you and I chatted about this some 3 or so years ago. Do you 
know if anyone of the (un)usual suspects have implemented?


Mark.

Re: Long hops on international paths

[Mark Tinka]

On 1/18/22 16:28, Saku Ytti wrote:


2) MPLS-TTL expires in transit
   2a) generate TTL exceeded and put it back to tunnel, sending it to
egressPE, which is guaranteed to know how to return to sender


This is what we run - our core is BGP-free (LDP), so the traceroute 
value customers see will be the egress PE router.



  2nd best is to tunnel, but the
RTT will confuse uneducated, or as it may be, hjghly educated, users.


It is very confusing, even for some educated users.

It's become less of problem, as years of educating users seems to have 
bedded in.



We could implement something like
https://ytti.github.io/icmp-eo-timestamp/draft-ytti-intarea-icmp-eo-timestamp.html
to offer correct forward latencies to P/LSR in 2a scenario.


I recall you and I chatted about this some 3 or so years ago. Do you 
know if anyone of the (un)usual suspects have implemented?


Mark.

Re: Long hops on international paths

[Saku Ytti]

On Tue, 18 Jan 2022 at 17:14, Michael Hare  wrote:

> AS3128 runs MPLS and it's probable someone might correct me here, but for a 
> IGP backbone area I think it's common for there to be a full mesh of LSPs via 
> either LDP, RSVP, SR etc.  AS3128 is a small regional and we operate in that 
> way across 60+ nodes.  I don't know if it's common for someone with a global 
> footprint like 1299 to have a contiguous global MPLS backbone, but the point 
> of my reply was to say it's not impossible to think 1299 has a global MPLS 
> mesh between major POPs.

Yes, this is the common case, not an exception.

-- 
  ++ytti

RE: Long hops on international paths

[Michael Hare via NANOG]

Paul-

You said: "... would decide to configure MPLS paths between Chicago and distant 
international locations ..."

AS3128 runs MPLS and it's probable someone might correct me here, but for a IGP 
backbone area I think it's common for there to be a full mesh of LSPs via 
either LDP, RSVP, SR etc.  AS3128 is a small regional and we operate in that 
way across 60+ nodes.  I don't know if it's common for someone with a global 
footprint like 1299 to have a contiguous global MPLS backbone, but the point of 
my reply was to say it's not impossible to think 1299 has a global MPLS mesh 
between major POPs.

-Michael

> -Original Message-
> From: NANOG  On
> Behalf Of PAUL R BARFORD
> Sent: Tuesday, January 18, 2022 8:16 AM
> To: Saku Ytti 
> Cc: Esteban Carisimo ;
> nanog@nanog.org; Fabian E. Bustamante 
> Subject: Re: Long hops on international paths
> 
> Hello Saku,
> 
> Thank you for the summary.  We're clear about the fact that what we're
> seeing are MLPS paths - that was not in question.  What we are not clear
> about and the reason for the post is why the provider - zayo.telia in this 
> case
> - would decide to configure MPLS paths between Chicago and distant
> international locations.  We assumed we would see hops in traceroute
> between Chicago and coastal locations and then hops that transited
> submarine infrastructure followed by hops to large population centers.
> 
> Regards, PB
> 
> 
> From: Saku Ytti 
> Sent: Tuesday, January 18, 2022 12:50 AM
> To: PAUL R BARFORD 
> Cc: Lukas Tribus ; Esteban Carisimo
> ; nanog@nanog.org
> ; Fabian E. Bustamante
> 
> Subject: Re: Long hops on international paths
> 
> 1) all (meaning all hitting the zayo.telia) your traceroutes originate
> from University in Chicago
> 2) the zayo.telia device is physically close to the university
> 3) we should expect physically close-by backbone device to be present
> in disproportionate amount of traceroutes
> 4) almost certainly zayo.telia is imposing the MPLS label of TTL 255,
> _NOT_ copying IP TTL, therefore until MPLS label is popped, TTL is not
> expiring. I.e. you are seeing ingressPE and egress PE ot Telia, you
> are not seeing any P routers.
> 
> This is not esoteric knowledge, but a fairly basic Internet concept. I
> am worried you are missing too much context to produce actionable
> output from your work. It might be interesting to see your curriculum,
> why this confusion arose, why it seems logical that the reason must be
> that almost all waves are terminated there, because it would not seem
> logical for people practising in the field who have even cursory
> understanding, this implies problems in the curriculum.
> 
> On Tue, 18 Jan 2022 at 07:21, PAUL R BARFORD  wrote:
> >
> > Please find the examples for the case of Telia below.
> >
> > FROM jfk-us (jfk-us.team-probing.c008820.20201002.warts.gz)
> >
> >
> >
> > traceroute from 216.66.30.102 (Ark probe hosted in New York City, NY, US.
> No AS info found) to 223.114.235.32 (MAXMIXD: Turpan, CN)
> >
> > 1  216.66.30.101  0.365 ms
> >
> > 2  62.115.49.173  3.182 ms
> >
> > 3  *
> >
> > 4  62.115.137.59  17.453 ms [x] (chi-b23-link.ip.twelve99.net., CAIDA-
> GEOLOC -> Chicago, IL, US)
> >
> > 5  62.115.117.48  59.921 ms [x] (sea-b2-link.ip.twelve99.net., RIPE-IPMAP ->
> Seattle, WA, US)
> >
> > 6  62.115.171.221  69.993 ms
> >
> > 7  223.120.6.53  69.378 ms
> >
> > 8  223.120.12.34  226.225 ms
> >
> > 9  221.183.55.110  237.475 ms
> >
> > 10  221.183.25.201  238.697 ms
> >
> > 11  221.176.16.213  242.296 ms
> >
> > 12  221.183.36.62  352.695 ms
> >
> > 13  221.183.39.2  300.166 ms
> >
> > 14  117.191.8.118  316.270 ms
> >
> > 15  *
> >
> > 16  *
> >
> > 17  *
> >
> > 18  *
> >
> > 19  *
> >
> >
> >
> >
> >
> > FROM ord-us (ord-us.team-probing.c008820.20201002.warts.gz)
> >
> >
> >
> > traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at
> Depaul University-AS20120) to 109.25.215.237 (237.215.25.109.rev.sfr.net.,
> MAXMIXD: La Crau, FR)
> >
> > 1  140.192.218.129  0.795 ms
> >
> > 2  140.192.9.124  0.603 ms
> >
> > 3  64.124.44.158  1.099 ms
> >
> > 4  64.125.31.172  3.047 ms
> >
> > 5  *
> >
> > 6  64.125.15.65  1.895 ms  [x] (zayo.telia.ter1.ord7.us.zip.zayo.com.,
> CAIDA-GEOLOC -> Chicago, IL, US)
> >
> > 7  62.115.118.59  99.242 ms[x] (prs-b3-link.ip.twelve99.net., CAIDA-
> GEOLOC -> Paris, FR)
> >
> > 8  62.115.154.23  105.214 ms
> >
> > 9  77.136.10.6  119.021 ms
> >
> > 10  77.136.10.6  118.830 ms
> >
> > 11  80.118.89.202  118.690 ms
> >
> > 12  80.118.89.234  118.986 ms
> >
> > 13  109.24.108.66  119.159 ms
> >
> > 14  109.25.215.237  126.085 ms
> >
> >
> >
> >
> >
> > traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at
> Depaul University-AS20120) to 84.249.89.93 (dsl-tkubng12-54f959-
> 93.dhcp.inet.fi., MAXMIXD: Turku, FI)
> >
> > 1  140.192.218.129  0.243 ms
> >
> > 2  140.192.9.124  0.326 ms
> >
> > 3  64.124.44.158  0.600 ms
> >
> > 4  *
> >
> > 5  *
> >
> > 6  

Re: home router battery backup

[Mark Tinka]

On 1/18/22 00:26, Jordan wrote:


Wow, that's a nice program.  Do you know what they keep the
"reserve percentage" set to, the proportion of stored energy that
will never be discharged for grid-support, but held back for
island-mode use in case of an outage?


I don't use the Tesla Powerwall, but Li-Ion is generally the same 
regardless of who packages it. The difference will be what the OEM 
decides to set the low-voltage cut-off to on the inverter and/or BMS.


I'm not sure how much the owner can configure a Tesla Powerwall, but 
with other installations, you can decide when your battery kicks in to 
run loads, or when it hands back to the grid or generator. This assumes 
evening time, when solar irradiation is unavailable, of course, as that 
is generally the preferred source of energy.


I've heard that Tesla will monitor the weather in your area to 
"pre-charge" the Powerwall to account for possible power disruptions. 
While I find that rather invasive, it's a cool feature for folk who 
"don't want to know". Then again, I also hear that Tesla will limit or 
withhold support and/or warranty if you do not connect your Powerwall to 
the Internet for them to "manage". The downside I hear, with that, is 
that they can remotely adjust SoH (state of health) thresholds to 
lengthen battery life in order to meet warranty promises. Not sure how 
true that is, but I've heard it a lot.


In terms of "reserve" capacity, Li-Ion can go much deeper than Lead 
Acid. Some inverters are setup to disconnect the battery anywhere 
between 3% - 20% SoC, depending on the OEM. For LFP chemistries, the BMS 
will usually turn the pack off at 2.50V, while for NMC, that will be 
around 2.75V. But different battery OEM's may be more or less aggressive 
with their BMS's, depending on who you choose to buy from.


Mark.

Re: Long hops on international paths

[PAUL R BARFORD]

Hello David,

Understanding the physical topology of the network is not​ our objective.  What 
we're trying to understand is the logical topology revealed by traceroute (we 
are well-aware of traceroute limitations) and why a relatively small set of 
routers in different countries tend to have the majority of the international 
connections.  Our expectation was that layer 3 connectivity revealed in 
traceroute to be relatively evenly spread out along coasts and near submarine 
landing points.  We're not seeing that.  So, the question is what is the 
cost/benefit to providers to configure/maintain routes (that include long MPLS 
tunnels) that tend to concentrate international connectivity at a relatively 
small number of routers?

Regards, PB

From: davidbass...@gmail.com 
Sent: Tuesday, January 18, 2022 8:22 AM
To: PAUL R BARFORD 
Cc: morrowc.li...@gmail.com ; nanog@nanog.org 

Subject: Re: Long hops on international paths

I think a large part of your problem is that you’re using trace route to try 
and determine the full topology of a large complex network.  It won’t show the 
full topology.

On Mon, Jan 17, 2022 at 7:43 PM PAUL R BARFORD 
mailto:p...@cs.wisc.edu>> wrote:
What we're considering specifically are consecutive (layer 3) hops as 
identified by traceroute.  Thus, TTL is decremented by 1 and no more than 1 
(i.e., we have to get full information (not *) from consecutive hops to 
consider the link).  I have asked my colleague to put together a set of 
examples.  We assume that there are multiple layer 1 and 2 links, and possibly 
layer 3 hops masked from traceroute by MPLS.  But what we're seeing in terms of 
hops exposed by traceroute make it look like a single (TTL decremented by 1) 
hop.

I'll post the examples when I get them.

PB

From: morrowc.li...@gmail.com 
mailto:morrowc.li...@gmail.com>>
Sent: Monday, January 17, 2022 5:13 PM
To: PAUL R BARFORD mailto:p...@cs.wisc.edu>>
Cc: Pengxiong Zhu mailto:pzhu...@ucr.edu>>; 
nanog@nanog.org 
mailto:nanog@nanog.org>>

Subject: Re: Long hops on international paths



On Mon, Jan 17, 2022 at 5:31 PM PAUL R BARFORD 
mailto:p...@cs.wisc.edu>> wrote:
Dear Pengxiong,

Thanks for your questions:


  1.  We are using CAIDA’s Internet Topology Data Kit (ITDK) that uses the 
MIDAR alias resolution method to infer IP addresses assigned to the same router.
  2.  We understand the concerns about IP geolocation.  Interfaces of the 
router in question are assigned similar domain names e.g., 
“chi-b2-link.ip.twelve99.net” 
(62.115.50.61). We also used CAIDA’s ITDK, which provides geolocation 
information, and indicates that this router is located in Chicago.  We 
cross-reference with Maxmind where possible.  In this particular case, there is 
the telltale in the use of "chi" in the domain name.
  3.

I think nick's point about ttl expiry and missing some context on topology 
still stands.
I'd be that the paths between 2 continents do not actually land in chicago... 
that you're seeing (or not seeing) missing hops between the coast(s) and 
chicago inside 1299's network in the US.


  1.

Hope that helps.

Regards, PB

From: Pengxiong Zhu mailto:pzhu...@ucr.edu>>
Sent: Monday, January 17, 2022 3:23 PM
To: PAUL R BARFORD mailto:p...@cs.wisc.edu>>
Cc: nanog@nanog.org 
mailto:nanog@nanog.org>>
Subject: Re: Long hops on international paths

Hi Paul,

Just curious. How do you determine they are the same routers? Is it based on IP 
address or MAC addresses? Or using CAIDA’s router alias database?

Also how do you draw the conclusion that the AS1299 router is indeed in 
Chicago? IP-geolocation based on rDNS is not always accurate though.


Pengxiong

On Mon, Jan 17, 2022 at 10:03 AM PAUL R BARFORD 
mailto:p...@cs.wisc.edu>> wrote:
Hello,

I am a researcher at the University of Wisconsin.  My colleagues at 
Northwestern University and I are studying international Internet connectivity 
and would appreciate your perspective on a recent finding.

We're using traceroute data from CAIDA's Ark project for our work.  We've 
observed that many international links (i.e., a single hop on an end-to-end 
path that connects two countries where end points on the hop are identified via 
rDNS) tend to originate/terminate at the same routers.  Said another way, we 
are observing a relatively small set of routers in different countries tend to 
have a majority of the international connections - this is especially the case 
for hops that terminate in the US.  For example, there is a router operated by 
Telia (AS1299) in Chicago that has a high concentration of such links.  We were 
a bit surprised by this finding since even though it makes sense that the set 
of providers is relatively small (i.e., those that offer global connectivity), 
we assumed that the set of routers that 

Re: Long hops on international paths

[Mike Hammett]

Chicago is a fairly major POP that *MAY* very well have waves right to other 
major POPs. 


Can you retest from a *not* major POP? They're not likely to have a wave from 
Indy, St. Louis, Des Moines, etc. going to Paris, Singapore, Helsinki, 
Budapest, etc. Then you could *maybe* determine if it's a wave or MPLS. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "PAUL R BARFORD"  
To: "Lukas Tribus"  
Cc: "Esteban Carisimo" , nanog@nanog.org, 
"Fabian E. Bustamante"  
Sent: Monday, January 17, 2022 11:17:18 PM 
Subject: Re: Long hops on international paths 


Please find the examples for the case of Telia below. 



FROM jfk-us (jfk-us.team-probing.c008820.20201002.warts.gz) 

traceroute from 216.66.30.102 (Ark probe hosted in New York City, NY, US. No AS 
info found) to 223.114.235.32 (MAXMIXD: Turpan, CN) 
1 216.66.30.101 0.365 ms 
2 62.115.49.173 3.182 ms 
3 * 
4 62.115.137.59 17.453 ms [x] (chi-b23-link.ip.twelve99.net., CAIDA-GEOLOC -> 
Chicago, IL, US) 
5 62.115.117.48 59.921 ms [x] (sea-b2-link.ip.twelve99.net., RIPE-IPMAP -> 
Seattle, WA, US) 
6 62.115.171.221 69.993 ms 
7 223.120.6.53 69.378 ms 
8 223.120.12.34 226.225 ms 
9 221.183.55.110 237.475 ms 
10 221.183.25.201 238.697 ms 
11 221.176.16.213 242.296 ms 
12 221.183.36.62 352.695 ms 
13 221.183.39.2 300.166 ms 
14 117.191.8.118 316.270 ms 
15 * 
16 * 
17 * 
18 * 
19 * 


FROM ord-us (ord-us.team-probing.c008820.20201002.warts.gz) 

traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at Depaul 
University-AS20120) to 109.25.215.237 (237.215.25.109.rev.sfr.net., MAXMIXD: La 
Crau, FR) 
1 140.192.218.129 0.795 ms 
2 140.192.9.124 0.603 ms 
3 64.124.44.158 1.099 ms 
4 64.125.31.172 3.047 ms 
5 * 
6 64.125.15.65 1.895 ms [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
CAIDA-GEOLOC -> Chicago, IL, US) 
7 62.115.118.59 99.242 ms [x] (prs-b3-link.ip.twelve99.net., CAIDA-GEOLOC -> 
Paris, FR) 
8 62.115.154.23 105.214 ms 
9 77.136.10.6 119.021 ms 
10 77.136.10.6 118.830 ms 
11 80.118.89.202 118.690 ms 
12 80.118.89.234 118.986 ms 
13 109.24.108.66 119.159 ms 
14 109.25.215.237 126.085 ms 


traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at Depaul 
University-AS20120) to 84.249.89.93 (dsl-tkubng12-54f959-93.dhcp.inet.fi., 
MAXMIXD: Turku, FI) 
1 140.192.218.129 0.243 ms 
2 140.192.9.124 0.326 ms 
3 64.124.44.158 0.600 ms 
4 * 
5 * 
6 64.125.15.65 1.792 ms [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
CAIDA-GEOLOC -> Chicago, IL, US) 
7 62.115.123.27 121.199 ms [x] (hls-b4-link.ip.twelve99.net., CAIDA-GEOLOC -> 
Helsinki, FI) 
8 * 
9 141.208.193.190 127.723 ms 
10 84.249.89.93 139.051 ms 


traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US) to 
193.28.231.50 (MAXMIXD: None, HU) 
1 140.192.218.129 0.240 ms 
2 140.192.9.124 0.333 ms 
3 64.124.44.158 0.648 ms 
4 * 
5 64.125.25.75 0.752 ms 
6 64.125.15.65 1.877 ms [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
CAIDA-GEOLOC -> Chicago, IL, US) 
7 62.115.119.39 123.952 ms [x] (bpt-b2-link.ip.twelve99.net., **I suspect it is 
in Budapest, HU**) 
8 62.115.39.122 117.171 ms 
9 88.151.96.148 117.202 ms 
10 88.151.96.213 124.787 ms 
11 * 
12 * 
13 * 
14 * 
15 * 


traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at Depaul 
University-AS20120) to 152.195.4.11 (MAXMIXD: Los Angeles, CA, US) 
1 140.192.218.129 0.224 ms 
2 140.192.9.124 0.545 ms 
3 64.124.44.158 0.640 ms 
4 * 
5 * 
6 64.125.15.65 1.786 ms [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
CAIDA-GEOLOC -> Chicago, IL, US) 
7 62.115.118.247 54.597 ms [x] (las-b22-link.ip.twelve99.net., CAIDA-GEOLOC -> 
Los Angeles, CA, US) 
8 62.115.11.129 55.979 ms 
9 * 
10 * 
11 * 
12 * 
13 * 


traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at Depaul 
University-AS20120) to 47.31.143.217 (MAXMIXD: Delhi, IN) 
1 140.192.218.129 2.277 ms 
2 140.192.9.124 0.449 ms 
3 64.124.44.158 0.576 ms 
4 * 
5 * 
6 64.125.15.65 1.814 ms [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
CAIDA-GEOLOC -> Chicago, IL, US) 
7 62.115.114.41 210.056 ms [x] (snge-b5-link.ip.twelve99.net.,) 
8 62.115.177.11 200.840 ms 
9 103.198.140.16 233.636 ms 
10 103.198.140.16 232.871 ms 
11 103.198.140.171 232.648 ms 
12 * 
13 * 
14 * 
15 * 
16 * 



From: Lukas Tribus  
Sent: Monday, January 17, 2022 1:52 PM 
To: PAUL R BARFORD  
Cc: Nick Hilliard ; nanog@nanog.org ; Esteban 
Carisimo ; Fabian E. Bustamante 
 
Subject: Re: Long hops on international paths 


On Mon, 17 Jan 2022 at 20:00, PAUL R BARFORD  wrote: 
> What we're curious about is why we're seeing a concentration of hops at a 
> small number of routers that appear on international paths. 

I suggest you share a few actual examples (IP addresses, traceroutes). 

I don't think discussing your conclusion based on data we don't have 
makes sense. 


Lukas 

Re: Long hops on international paths

[Saku Ytti]

Hey Paul,

> Thank you for the summary.  We're clear about the fact that what we're seeing 
> are MLPS paths - that was not in question.  What we are not clear about and 
> the reason for the post is why the provider - zayo.telia in this case - would 
> decide to configure MPLS paths between Chicago and distant international 
> locations.  We assumed we would see hops in traceroute between Chicago and 
> coastal locations and then hops that transited submarine infrastructure 
> followed by hops to large population centers.

MPLS is the default, not exception.

And like any other form of tunnelling, MPLS decouples underlay and overlay.

This means, the key value proposal of tunneling is that the devices
between tunnel end points do not know the original sender or final
receiver. This means, when TTL expires in transit, the P device may
not know how to return packet to sender.

There are three cases here

1) MPLS-TTL does not expire in transit => easy
2) MPLS-TTL expires in transit
  2a) generate TTL exceeded and put it back to tunnel, sending it to
egressPE, which is guaranteed to know how to return to sender
  2b) randomly assume that you know how to reach the sender and try to
send the TTL exceeded directly


with 2a) all P hops display egressPE latency, but it works. With 2b)
it might not work, as P might not know how to return. Some devices,
like Cisco, allows you heuristically to decide if to tunnel ICMP or
not, based on stack depth, but this does not work. As default table
during repair is as deep as vrf without repair, so we cannot really
discriminate.

So the best solution is to not expire in transit (the norm in
tunneling), i.e. set MPLS-TTL to 255. 2nd best is to tunnel, but the
RTT will confuse uneducated, or as it may be, hjghly educated, users.
We could implement something like
https://ytti.github.io/icmp-eo-timestamp/draft-ytti-intarea-icmp-eo-timestamp.html
to offer correct forward latencies to P/LSR in 2a scenario.



>
> Regards, PB
> 
> From: Saku Ytti 
> Sent: Tuesday, January 18, 2022 12:50 AM
> To: PAUL R BARFORD 
> Cc: Lukas Tribus ; Esteban Carisimo 
> ; nanog@nanog.org ; 
> Fabian E. Bustamante 
> Subject: Re: Long hops on international paths
>
> 1) all (meaning all hitting the zayo.telia) your traceroutes originate
> from University in Chicago
> 2) the zayo.telia device is physically close to the university
> 3) we should expect physically close-by backbone device to be present
> in disproportionate amount of traceroutes
> 4) almost certainly zayo.telia is imposing the MPLS label of TTL 255,
> _NOT_ copying IP TTL, therefore until MPLS label is popped, TTL is not
> expiring. I.e. you are seeing ingressPE and egress PE ot Telia, you
> are not seeing any P routers.
>
> This is not esoteric knowledge, but a fairly basic Internet concept. I
> am worried you are missing too much context to produce actionable
> output from your work. It might be interesting to see your curriculum,
> why this confusion arose, why it seems logical that the reason must be
> that almost all waves are terminated there, because it would not seem
> logical for people practising in the field who have even cursory
> understanding, this implies problems in the curriculum.
>
> On Tue, 18 Jan 2022 at 07:21, PAUL R BARFORD  wrote:
> >
> > Please find the examples for the case of Telia below.
> >
> > FROM jfk-us (jfk-us.team-probing.c008820.20201002.warts.gz)
> >
> >
> >
> > traceroute from 216.66.30.102 (Ark probe hosted in New York City, NY, US. 
> > No AS info found) to 223.114.235.32 (MAXMIXD: Turpan, CN)
> >
> > 1  216.66.30.101  0.365 ms
> >
> > 2  62.115.49.173  3.182 ms
> >
> > 3  *
> >
> > 4  62.115.137.59  17.453 ms [x] (chi-b23-link.ip.twelve99.net., 
> > CAIDA-GEOLOC -> Chicago, IL, US)
> >
> > 5  62.115.117.48  59.921 ms [x] (sea-b2-link.ip.twelve99.net., RIPE-IPMAP 
> > -> Seattle, WA, US)
> >
> > 6  62.115.171.221  69.993 ms
> >
> > 7  223.120.6.53  69.378 ms
> >
> > 8  223.120.12.34  226.225 ms
> >
> > 9  221.183.55.110  237.475 ms
> >
> > 10  221.183.25.201  238.697 ms
> >
> > 11  221.176.16.213  242.296 ms
> >
> > 12  221.183.36.62  352.695 ms
> >
> > 13  221.183.39.2  300.166 ms
> >
> > 14  117.191.8.118  316.270 ms
> >
> > 15  *
> >
> > 16  *
> >
> > 17  *
> >
> > 18  *
> >
> > 19  *
> >
> >
> >
> >
> >
> > FROM ord-us (ord-us.team-probing.c008820.20201002.warts.gz)
> >
> >
> >
> > traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at 
> > Depaul University-AS20120) to 109.25.215.237 (237.215.25.109.rev.sfr.net., 
> > MAXMIXD: La Crau, FR)
> >
> > 1  140.192.218.129  0.795 ms
> >
> > 2  140.192.9.124  0.603 ms
> >
> > 3  64.124.44.158  1.099 ms
> >
> > 4  64.125.31.172  3.047 ms
> >
> > 5  *
> >
> > 6  64.125.15.65  1.895 ms  [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
> > CAIDA-GEOLOC -> Chicago, IL, US)
> >
> > 7  62.115.118.59  99.242 ms[x] (prs-b3-link.ip.twelve99.net., 
> > CAIDA-GEOLOC -> Paris, FR)
> >
> > 8  62.115.154.23  105.214 

Re: Long hops on international paths

[David Bass]

I think a large part of your problem is that you’re using trace route to
try and determine the full topology of a large complex network.  It won’t
show the full topology.

On Mon, Jan 17, 2022 at 7:43 PM PAUL R BARFORD  wrote:

> What we're considering specifically are consecutive (layer 3) hops as
> identified by traceroute.  Thus, TTL is decremented by 1 and no more than 1
> (i.e., we have to get full information (not *) from consecutive hops to
> consider the link).  I have asked my colleague to put together a set of
> examples.  We assume that there are multiple layer 1 and 2 links, and
> possibly layer 3 hops masked from traceroute by MPLS.  But what we're
> seeing in terms of hops exposed by traceroute make it look like a single
> (TTL decremented by 1) hop.
>
> I'll post the examples when I get them.
>
> PB
> --
> *From:* morrowc.li...@gmail.com 
> *Sent:* Monday, January 17, 2022 5:13 PM
> *To:* PAUL R BARFORD 
> *Cc:* Pengxiong Zhu ; nanog@nanog.org 
>
> *Subject:* Re: Long hops on international paths
>
>
>
> On Mon, Jan 17, 2022 at 5:31 PM PAUL R BARFORD  wrote:
>
> Dear Pengxiong,
>
> Thanks for your questions:
>
>
>1. We are using CAIDA’s Internet Topology Data Kit (ITDK) that uses
>the MIDAR alias resolution method to infer IP addresses assigned to the
>same router.
>2. We understand the concerns about IP geolocation.  Interfaces of the
>router in question are assigned similar domain names e.g., “
>chi-b2-link.ip.twelve99.net” (62.115.50.61). We also used CAIDA’s
>ITDK, which provides geolocation information, and indicates that this
>router is located in Chicago.  We cross-reference with Maxmind where
>possible.  In this particular case, there is the telltale in the use of
>"chi" in the domain name.
>3.
>
>
> I think nick's point about ttl expiry and missing some context on
> topology still stands.
> I'd be that the paths between 2 continents do not actually land in
> chicago... that you're seeing (or not seeing) missing hops between the
> coast(s) and chicago inside 1299's network in the US.
>
>
>
>1.
>
> Hope that helps.
>
> Regards, PB
> --
> *From:* Pengxiong Zhu 
> *Sent:* Monday, January 17, 2022 3:23 PM
> *To:* PAUL R BARFORD 
> *Cc:* nanog@nanog.org 
> *Subject:* Re: Long hops on international paths
>
> Hi Paul,
>
> Just curious. How do you determine they are the same routers? Is it based
> on IP address or MAC addresses? Or using CAIDA’s router alias database?
>
> Also how do you draw the conclusion that the AS1299 router is indeed in
> Chicago? IP-geolocation based on rDNS is not always accurate though.
>
>
> Pengxiong
>
> On Mon, Jan 17, 2022 at 10:03 AM PAUL R BARFORD  wrote:
>
> Hello,
>
> I am a researcher at the University of Wisconsin.  My colleagues at
> Northwestern University and I are studying international Internet
> connectivity and would appreciate your perspective on a recent finding.
>
> We're using traceroute data from CAIDA's Ark project for our work.  We've 
> observed
> that many international links (i.e., a single hop on an end-to-end path
> that connects two countries where end points on the hop are identified via
> rDNS) tend to originate/terminate at the same routers.  Said another way,
> we are observing a relatively small set of routers in different countries
> tend to have a majority of the international connections - this is
> especially the case for hops that terminate in the US.  For example,
> there is a router operated by Telia (AS1299) in Chicago that has a high
> concentration of such links.  We were a bit surprised by this finding since
> even though it makes sense that the set of providers is relatively small
> (i.e., those that offer global connectivity), we assumed that the set of
> routers that used for international connectivity within any one country
> would tend to be more widely distributed (at least with respect to how they
> appear in traceroute data - MPLS notwithstanding).
>
> We're interested in whether or not this is indeed standard practice and if
> so, the cost/benefit for configuring international connectivity in this
> way?
>
> Any thoughts or insights you might have would be greatly appreciated -
> off-list responses are welcome.
>
> Thank you.
>
> Regards, PB
>
> Paul Barford
> University of Wisconsin - Madison
>
> --
>
> Regards,
> Pengxiong Zhu
> Department of Computer Science and Engineering
> University of California, Riverside
>
>

Re: Long hops on international paths

[PAUL R BARFORD]

Hello Saku,

Thank you for the summary.  We're clear about the fact that what we're seeing 
are MLPS paths - that was not in question.  What we are not clear about and the 
reason for the post is why the provider - zayo.telia in this case - would 
decide to configure MPLS paths between Chicago and distant international 
locations.  We assumed we would see hops in traceroute between Chicago and 
coastal locations and then hops that transited submarine infrastructure 
followed by hops to large population centers.

Regards, PB

From: Saku Ytti 
Sent: Tuesday, January 18, 2022 12:50 AM
To: PAUL R BARFORD 
Cc: Lukas Tribus ; Esteban Carisimo 
; nanog@nanog.org ; Fabian 
E. Bustamante 
Subject: Re: Long hops on international paths

1) all (meaning all hitting the zayo.telia) your traceroutes originate
from University in Chicago
2) the zayo.telia device is physically close to the university
3) we should expect physically close-by backbone device to be present
in disproportionate amount of traceroutes
4) almost certainly zayo.telia is imposing the MPLS label of TTL 255,
_NOT_ copying IP TTL, therefore until MPLS label is popped, TTL is not
expiring. I.e. you are seeing ingressPE and egress PE ot Telia, you
are not seeing any P routers.

This is not esoteric knowledge, but a fairly basic Internet concept. I
am worried you are missing too much context to produce actionable
output from your work. It might be interesting to see your curriculum,
why this confusion arose, why it seems logical that the reason must be
that almost all waves are terminated there, because it would not seem
logical for people practising in the field who have even cursory
understanding, this implies problems in the curriculum.

On Tue, 18 Jan 2022 at 07:21, PAUL R BARFORD  wrote:
>
> Please find the examples for the case of Telia below.
>
> FROM jfk-us (jfk-us.team-probing.c008820.20201002.warts.gz)
>
>
>
> traceroute from 216.66.30.102 (Ark probe hosted in New York City, NY, US. No 
> AS info found) to 223.114.235.32 (MAXMIXD: Turpan, CN)
>
> 1  216.66.30.101  0.365 ms
>
> 2  62.115.49.173  3.182 ms
>
> 3  *
>
> 4  62.115.137.59  17.453 ms [x] (chi-b23-link.ip.twelve99.net., CAIDA-GEOLOC 
> -> Chicago, IL, US)
>
> 5  62.115.117.48  59.921 ms [x] (sea-b2-link.ip.twelve99.net., RIPE-IPMAP -> 
> Seattle, WA, US)
>
> 6  62.115.171.221  69.993 ms
>
> 7  223.120.6.53  69.378 ms
>
> 8  223.120.12.34  226.225 ms
>
> 9  221.183.55.110  237.475 ms
>
> 10  221.183.25.201  238.697 ms
>
> 11  221.176.16.213  242.296 ms
>
> 12  221.183.36.62  352.695 ms
>
> 13  221.183.39.2  300.166 ms
>
> 14  117.191.8.118  316.270 ms
>
> 15  *
>
> 16  *
>
> 17  *
>
> 18  *
>
> 19  *
>
>
>
>
>
> FROM ord-us (ord-us.team-probing.c008820.20201002.warts.gz)
>
>
>
> traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at 
> Depaul University-AS20120) to 109.25.215.237 (237.215.25.109.rev.sfr.net., 
> MAXMIXD: La Crau, FR)
>
> 1  140.192.218.129  0.795 ms
>
> 2  140.192.9.124  0.603 ms
>
> 3  64.124.44.158  1.099 ms
>
> 4  64.125.31.172  3.047 ms
>
> 5  *
>
> 6  64.125.15.65  1.895 ms  [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
> CAIDA-GEOLOC -> Chicago, IL, US)
>
> 7  62.115.118.59  99.242 ms[x] (prs-b3-link.ip.twelve99.net., 
> CAIDA-GEOLOC -> Paris, FR)
>
> 8  62.115.154.23  105.214 ms
>
> 9  77.136.10.6  119.021 ms
>
> 10  77.136.10.6  118.830 ms
>
> 11  80.118.89.202  118.690 ms
>
> 12  80.118.89.234  118.986 ms
>
> 13  109.24.108.66  119.159 ms
>
> 14  109.25.215.237  126.085 ms
>
>
>
>
>
> traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at 
> Depaul University-AS20120) to 84.249.89.93 
> (dsl-tkubng12-54f959-93.dhcp.inet.fi., MAXMIXD: Turku, FI)
>
> 1  140.192.218.129  0.243 ms
>
> 2  140.192.9.124  0.326 ms
>
> 3  64.124.44.158  0.600 ms
>
> 4  *
>
> 5  *
>
> 6  64.125.15.65  1.792 ms  [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
> CAIDA-GEOLOC -> Chicago, IL, US)
>
> 7  62.115.123.27  121.199 ms   [x] (hls-b4-link.ip.twelve99.net., 
> CAIDA-GEOLOC -> Helsinki, FI)
>
> 8  *
>
> 9  141.208.193.190  127.723 ms
>
> 10  84.249.89.93  139.051 ms
>
>
>
>
>
> traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US) to 
> 193.28.231.50 (MAXMIXD: None, HU)
>
> 1  140.192.218.129  0.240 ms
>
> 2  140.192.9.124  0.333 ms
>
> 3  64.124.44.158  0.648 ms
>
> 4  *
>
> 5  64.125.25.75  0.752 ms
>
> 6  64.125.15.65  1.877 ms  [x] (zayo.telia.ter1.ord7.us.zip.zayo.com., 
> CAIDA-GEOLOC -> Chicago, IL, US)
>
> 7  62.115.119.39  123.952 ms   [x] (bpt-b2-link.ip.twelve99.net., **I suspect 
> it is in Budapest, HU**)
>
> 8  62.115.39.122  117.171 ms
>
> 9  88.151.96.148  117.202 ms
>
> 10  88.151.96.213  124.787 ms
>
> 11  *
>
> 12  *
>
> 13  *
>
> 14  *
>
> 15  *
>
>
>
>
>
> traceroute from 140.192.218.138 (Ark probe hosted in Chicago, IL, US at 
> Depaul University-AS20120) to 152.195.4.11 (MAXMIXD: Los Angeles, CA, US)
>
> 1  140.192.218.129  0.224 ms
>
> 2  140.192.9.124  0.545 ms
>
> 3  

Re: home router battery backup

[Jordan]

On Thu, Jan 13, 2022 at 02:06:39PM -0800, Michael Thomas wrote:
>
> For my ISP, they maintain backup power for both DSL and POTS.  I
> suspect that for a lot of DSL that would hold true because it's
> relatively easy for them to power since they already have the
> battery backup requirements for POTS.  The setup they have here
> is a DSLAM and SIP->POTS termination in a pedestal with fiber
> backhaul.  They use the old copper that used to go back to the CO
> to power the pedestal.

Do you happen to know what voltage is placed across the copper pairs
for this purpose?  Maybe 130V like T1 span repeaters?  More?

I used to have three POTS lines at home from BellSouth, before the
AT acquisition, with DSL on one of them, all supposedly served
from the same Lucent SLC.  One of these, the one originally used
for DSL, would always go down for both voice and data when the SLC
lost power-- no DC, no dialtone, no DSL, while the other two
remained up.  Despite several claims of a resolution, this was
never properly fixed, so eventually I just had them move DSL over
to one of the unaffected lines.

I could never understand what failure mode would result in losing
just a single POTS line like this while the carrier equipment was
running from battery, while others remained in service. 
Speculating, perhaps only the A or B-side was backed up, and an
open diode or other defect caused a single ine card to draw only
from the "other" source?  But, at this time (circa 2000) the remote
DSLAM was definitely a separate piece of equipment, right, joined
to a shared subscriber pair with passive splitters?

> Mike

-- 
Jordan.

Re: home router battery backup

[Jordan]

On Thu, Jan 13, 2022 at 10:29:13PM +, John Lightfoot wrote:
>
> In Vermont I have a Tesla Powerwall that Green Mountain Power
> paid for if I agreed to let them manage it.  Since then I've
> never had an outage of any kind, I usually figure out that there
> is one by seeing my neighbors' lights go off.

Wow, that's a nice program.  Do you know what they keep the
"reserve percentage" set to, the proportion of stored energy that
will never be discharged for grid-support, but held back for
island-mode use in case of an outage?

> I've also had great luck with my ISP, which is Comcast.  Even
> before we had the Powerwall, when the power would go out the
> (older) Comcast router would work on its own battery backup and
> my laptop would flip over to battery power, so I didn't have any
> loss of connectivity even then.

In my part of northeast Florida, although Comcast has installed
outside-plant batteries when extending service to new developments,
as of 2015 they would wait until customers complained (or perhaps
until "enough" ordered their voice service) to upgrade older
neighborhoods.

Service in my area used to drop immediately at even a fractional-
second grid power glitch, despite having many hours of backup on my
end.  It took about two months of nagging them to get the Alpha
Power box supporting our fiber<->coax node and line amps replaced
with one containing batteries, and nearly as long for a friend
across town in the same position.

Although I don't have Comcast voice service, instead using my own
over-the-top VoIP, several neighbors already did by this time.  I'm
surprised they weren't concerned for liabiilty over failed 911 calls.

Hopefully this policy has improved in the years since, but their
lack of proactive replacement of failed outside-plant batteries
suggests otherwise.  Rather than changing these out on a schedule,
or when failure is signaled by the equipment, they still appear to
wait until someone complains, after which expired batteries *might*
get swapped in a month or so.

Voice-capable gateways and eMTA's provided to Comcast Business
customers do contain lithium batteries good for several hours of
service, longer than most PBXes are backed up for, but of course
these are of no use when the outside plant lacks backup.

For residential customers, they seem to be charging a considerable
premium for the battery option:

https://www.xfinity.com/support/articles/getting-a-new-battery

"A backup battery for certain Comcast-provided modems can be
purchased from Comcast at any time and are currently priced at
$165, plus tax.  Your purchase includes 24 hours of standby time, a
one-year warranty and monitoring to determine when you need to
purchase a new battery."

-- 
Jordan.

ODP: SOHO IPv6 switches

[Marcin Gondek]

Hi Sean,

Cisco SG250?

Thanks,

--
Marcin Gondek / Drixter
http://fido.e-utp.net/
AS56662

Od: NANOG  w imieniu użytkownika 
Sean Donelan 
Wysłane: wtorek, 18 stycznia 2022 12:28
Do: nanog@nanog.org 
Temat: SOHO IPv6 switches


Of course, any ethernet switch is "IPv6 ready."  They are just ethernet
packets, and the switch doesn't care what's in the packets.

Which SOHO class switches are really IPv6 capable?  Or is it still
necessary to go with the enterprise class switches?

IOT devices all want to chat with each other even if there is no upstream
IPv6 (Verizon FIOS).  IGMPv3 snooping and IPv4 controls keep IPv4
broadcast storms under control.  But SOHO-class switches don't seem to
have the same capabilities for IPv6.

The top two capabilities: 1) MLD snooping and 2) a simple way to keep IPv6
off certain ports (i.e. ancient 10/100 devices, which don't like it.
controlling the multicast floods may also help them).

What's the goto SOHO-class switch for IPv6?

Re: SOHO IPv6 switches

[Mikael Abrahamsson via NANOG]

On Tue, 18 Jan 2022, Sean Donelan wrote:


What's the goto SOHO-class switch for IPv6?


Zyxel/Netgear/TP-Link all have switches in the 100-200USD range that can 
do some basic stuff (filter on ethertype, some DHCPv6/RA inspection, SNMP 
polling via IPv6 etc).


I was surprised by what I found (and this was 5-8 years ago), but I never 
went all-in on testing all of this, but looking at the feature set it 
actually seemed like they tried to support BCP38/SAVI, so I imagine some 
of these switches are actually used by ISPs as ETTH equipment.


https://www.tp-link.com/us/business-networking/managed-switch/tl-sg3428/v2/

"IPv6 functions such as Dual IPv4/IPv6 Stack, MLD Snooping, IPv6 ACL, 
DHCPv6 Snooping..."


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: SOHO IPv6 switches

[Nick Hilliard]

Sean Donelan wrote on 18/01/2022 11:28:

The top two capabilities: 1) MLD snooping and 2) a simple way to keep
IPv6 off certain ports (i.e. ancient 10/100 devices, which don't like
it. controlling the multicast floods may also help them).


Most people don't use ipv6 multicast in anger (i.e. anything more than 
nd / bonjour / etc), so mld snooping isn't that important for small 
switches.


For proper device access control, you also need the ability for the 
switch to do ND/RA + DHCP snooping / filtering.  Otherwise you open 
yourself to rogue routers and/or address assignment.


Nick

SOHO IPv6 switches

[Sean Donelan]

Of course, any ethernet switch is "IPv6 ready."  They are just ethernet 
packets, and the switch doesn't care what's in the packets.


Which SOHO class switches are really IPv6 capable?  Or is it still 
necessary to go with the enterprise class switches?


IOT devices all want to chat with each other even if there is no upstream 
IPv6 (Verizon FIOS).  IGMPv3 snooping and IPv4 controls keep IPv4 
broadcast storms under control.  But SOHO-class switches don't seem to 
have the same capabilities for IPv6.


The top two capabilities: 1) MLD snooping and 2) a simple way to keep IPv6 
off certain ports (i.e. ancient 10/100 devices, which don't like it. 
controlling the multicast floods may also help them).


What's the goto SOHO-class switch for IPv6?