Re: California public safety power shutdowns

[Javier J]

I have an alternative view. the more generators are running, the more
trucks semt to refuel the tanks, the more moving parts, the more likely an
accident is prone to happen somewhere. It's thr same reason you turn your
vehicles engine off when you fill up at the gas station.

Diesel doesn't combust easily without conpression, but I'm pretty sure you
can find incidents where diesel engines catch fire. maybe the roof of a
datacenter is not a risk factor, but in thinking remote antennas on the top
of a mountain anything can happen.

On Thu, Oct 10, 2019, 8:52 PM Mel Beckman  wrote:

> Sean,
>
> A diesel generator sparking a fire is extremely unlikely. A diesel
> generator by code must have a clear, nonflammable, area around it, and a
> spark arrestor on the exhaust to protect against burning particles in the
> exhaust. Diesel generators are not even a listed cause according to the
> National Wildfire Coordinating Group:
>
> https://www.nwcg.gov/sites/default/files/publications/pms412.pdf
>
> Let’s not go making up fantastical monsters. There are plenty of real
> monsters to go around :)
>
>  -mel
>
> On Oct 10, 2019, at 5:29 PM, Ca By  wrote:
>
> I just hope the next fire is not sparked by a diesel generator that is
> running because commercial power is off.
>
> On Thu, Oct 10, 2019 at 3:48 PM Sean Donelan  wrote:
>
>>
>>
>> AT statement:
>>
>> Like all PG customers, we are also affected by this power shutdown.
>> Overall our network continues to perform well and is operating at more
>> than 97% cause
>
> of normal. We are aware that service for some customers may be
>> affected by this event and are working as quickly as possible to deploy
>> additional generators and recovery equipment. We appreciate our
>> customer’s
>> patience.
>>
>>
>> T-Mobile statement:
>>
>> The T-Mobile network is holding up well during the ongoing PG and SCE
>> safety power shut offs in California. We are seeing a small number of
>> sites down in some of the areas affected by the power shut off.
>>
>> Our response teams are working to get sites back up and running as
>> quickly
>> as possible. We understand that service disruptions are an inconvenience
>> to our customers and we appreciate their patience during this event.
>>
>>
>> Verizon:
>>
>> Verizon spokeswoman Jeannine Brew Braggs said the company can serve
>> customers "indefinitely" until commercial power is restored. She
>> attributed that to the generators and backup batteries on-site at the
>> majority of its cell towers and other locations. Brew Braggs said the
>> company can refuel the generators to keep them running.
>>
>>
>> I'm still looking for statements from Sprint and US Cellular.
>>
>

Graphical databases ?

[Craig]

Has anyone used the graphical data base software:
https://neo4j.com/

I looked at this software several years ago, but it will still relatively
new.
We are exploring using this to create dependencies of our network
infrastructure hardware, customer information, etc. etc.

here is an example:
https://neo4j.com/graphgist/network-dependency-graph

For those that have used it:
Has anyone been able to successfully use this for their networks?
pros/cons/good/bad

Is maintaining the data a chore?
Has it helped operationally?

if anyone has any input would appreciate hearing from you;

thanks;

CPV

Re: California public safety power shutdowns

[Mel Beckman]

Sean,

A diesel generator sparking a fire is extremely unlikely. A diesel generator by 
code must have a clear, nonflammable, area around it, and a spark arrestor on 
the exhaust to protect against burning particles in the exhaust. Diesel 
generators are not even a listed cause according to the National Wildfire 
Coordinating Group:

https://www.nwcg.gov/sites/default/files/publications/pms412.pdf

Let’s not go making up fantastical monsters. There are plenty of real monsters 
to go around :)

 -mel

On Oct 10, 2019, at 5:29 PM, Ca By 
mailto:cb.li...@gmail.com>> wrote:

I just hope the next fire is not sparked by a diesel generator that is running 
because commercial power is off.

On Thu, Oct 10, 2019 at 3:48 PM Sean Donelan 
mailto:s...@donelan.com>> wrote:


AT statement:

Like all PG customers, we are also affected by this power shutdown.
Overall our network continues to perform well and is operating at more
than 97% cause
of normal. We are aware that service for some customers may be
affected by this event and are working as quickly as possible to deploy
additional generators and recovery equipment. We appreciate our customer’s
patience.


T-Mobile statement:

The T-Mobile network is holding up well during the ongoing PG and SCE
safety power shut offs in California. We are seeing a small number of
sites down in some of the areas affected by the power shut off.

Our response teams are working to get sites back up and running as quickly
as possible. We understand that service disruptions are an inconvenience
to our customers and we appreciate their patience during this event.


Verizon:

Verizon spokeswoman Jeannine Brew Braggs said the company can serve
customers "indefinitely" until commercial power is restored. She
attributed that to the generators and backup batteries on-site at the
majority of its cell towers and other locations. Brew Braggs said the
company can refuel the generators to keep them running.


I'm still looking for statements from Sprint and US Cellular.

Re: California public safety power shutdowns

[Ca By]

I just hope the next fire is not sparked by a diesel generator that is
running because commercial power is off.

On Thu, Oct 10, 2019 at 3:48 PM Sean Donelan  wrote:

>
>
> AT statement:
>
> Like all PG customers, we are also affected by this power shutdown.
> Overall our network continues to perform well and is operating at more
> than 97% cause

of normal. We are aware that service for some customers may be
> affected by this event and are working as quickly as possible to deploy
> additional generators and recovery equipment. We appreciate our customer’s
> patience.
>
>
> T-Mobile statement:
>
> The T-Mobile network is holding up well during the ongoing PG and SCE
> safety power shut offs in California. We are seeing a small number of
> sites down in some of the areas affected by the power shut off.
>
> Our response teams are working to get sites back up and running as quickly
> as possible. We understand that service disruptions are an inconvenience
> to our customers and we appreciate their patience during this event.
>
>
> Verizon:
>
> Verizon spokeswoman Jeannine Brew Braggs said the company can serve
> customers "indefinitely" until commercial power is restored. She
> attributed that to the generators and backup batteries on-site at the
> majority of its cell towers and other locations. Brew Braggs said the
> company can refuel the generators to keep them running.
>
>
> I'm still looking for statements from Sprint and US Cellular.
>

Re: California public safety power shutdowns

[Sean Donelan]

Comcast statement:

Hi. Parts of our network that connect to your Xfinity service may be in 
areas where the commercial power is off leading to a disruption. Once 
power is fully restored to those parts of the network, and it is safe to 
do so, we will restore service ASAP.

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Dennis Lundström]

Feel that this is more down the line of RFC 7511, no? ;-)

—Dennis


On Tue, Oct 8, 2019 at 07:25 J. Hellenthal via NANOG 
wrote:

> See RFC 1149 & 2549
>
> ;-)
>
> --
>  J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says
> a lot about anticipated traffic volume.
>
> > On Oct 7, 2019, at 11:29, Keith Medcalf  wrote:
> >
> > 
> >> On Monday, 7 October, 2019 08:55, Rich Kulawiec  wrote:
> >>
> >> On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote:
> >
> >>> Otherwise, an impressive amount of WTF. My favorite: "while
> >>> communication by servers ___on the ground___ might take hundreds of
> >>> milliseconds, in the cloud the same operation may take only one
> >>> millisecond from one machine to another"
> >
> >> My favorite: "The researchers expect their cloud-based system will be
> >> more secure than the Internet is today [...]"  Apparently they're
> > blissfully
> >> unaware that there is no such thing as "cloud security".
> >
> > I would be interested to know how one connects to their "cloud"?  Do I
> > need an "Evaporation Adapter" for my computer to send to their cloud?
> > And do I need a "Rain Collector" to receive from it?  I suppose I also
> > need the computer to be outside exposed to the elements -- putting it
> > under a brolly would interfere with incoming rain from the cloud ...
> > Plus I suppose it would not work very well at all in the desert, but
> > downloading would be very high bandwidth in the rainforest (or during
> > monsoon season).
> >
> > :)
> >
> > --
> > The fact that there's a Highway to Hell but only a Stairway to Heaven
> > says a lot about anticipated traffic volume.
> >
> >
> >
>

Re: California public safety power shutdowns

[Sean Donelan]

AT statement:

Like all PG customers, we are also affected by this power shutdown. 
Overall our network continues to perform well and is operating at more 
than 97% of normal. We are aware that service for some customers may be 
affected by this event and are working as quickly as possible to deploy 
additional generators and recovery equipment. We appreciate our customer’s 
patience.



T-Mobile statement:

The T-Mobile network is holding up well during the ongoing PG and SCE 
safety power shut offs in California. We are seeing a small number of 
sites down in some of the areas affected by the power shut off.


Our response teams are working to get sites back up and running as quickly 
as possible. We understand that service disruptions are an inconvenience 
to our customers and we appreciate their patience during this event.



Verizon:

Verizon spokeswoman Jeannine Brew Braggs said the company can serve 
customers "indefinitely" until commercial power is restored. She 
attributed that to the generators and backup batteries on-site at the 
majority of its cell towers and other locations. Brew Braggs said the 
company can refuel the generators to keep them running.



I'm still looking for statements from Sprint and US Cellular.

Re: California public safety power shutdowns

[Javier J]

Reminds me of Enron days.

On Thu, Oct 10, 2019 at 2:06 PM Michael Thomas  wrote:

>
> On 10/10/19 10:40 AM, Randy Bush wrote:
> >> Pacific Gas & Electric and Southern California Edison have started
> >> Public Safety Power Shut-offs (PSPS) in California wildfire high-risk
> >> areas.
> > not exactly
> >
> > the diablo winds are way north in the state.  but much of the power
> > for the big metros is bought from the hydros in the northwest and
> > has to come on lines through the windy area.
> >
> > for some years, pg traded short term profits for long term risk by
> > not clearing the lines.  their long term risk cost lives, jillions in
> > property and other damage last fire season.
> >
> > now pg is in a severe liability pickle and madly trying to shovel
> > kitty litter over it.
> >
> > the high risk is putting stockholders and profit before public safety
> > and service.
> >
> It's also pretty clear that this is revenge pr0n for us getting all
> upset for them burning down paradise.
>
> I'm fairly certain that tech can help this problem along significantly,
> but that might cut into e-staff bonuses.
>
>
> https://wildfiremitigation.tees.tamus.edu/faqs/other-monitoring-benefits
>
>
> Mike
>
>

Re: worse than IPv6 Pain Experiment

[bzs]

On October 9, 2019 at 17:12 b...@herrin.us (William Herrin) wrote:
 > On Wed, Oct 9, 2019 at 4:30 PM John R. Levine  wrote:
 > > > Can I summarize the current round of objections to my admittedly
 > > > off-beat proposal (use basically URLs rather than IP addresses in IP
 > > > packet src/dest) as:
 > > >
 > > >  We can't do that! It would require changing something!
 > >
 > > Nope.  You can summarize it as "it doesn't scale", which is what has
 > > killed endless numbers of superficially plausible bad ideas.
 > 
 > And Barry's been around long enough to know this. What's up Barry? What's the
 > meta-argument you're trying to make here 'cause "bits is bits" is about as
 > smart as telling a chef that "food is food."

Some brought up objections to IPv6 one of which was that its long hex
strings are difficult to remember compared to IPv4 addresses.

I first suggested that might be largly a human interface issue more
than a flaw in the design.

Then I remembered a talk I gave in Singapore, intended to be
controversial, suggesting the use of essentially URLs as a superset of
"domain names", but whatever, everyone knows what I mean, as actual
addresses in packets.

Just trying to stimulate some thinking beyond IPv6 and assessing where
we are in general terms regarding for example changes in hardware etc
availability since IPv6 was first being developed ca 1990.

Particularly in a context where the less than stellar adoption of IPv6
is an issue.

Some, most, of the comments have been very interesting and also
thought-provoking.

Others amounted to "but where do we put the gasoline in this
new-fangled electric car?!" (yes some fundamental things would need to
be redesigned), some wanted the entire design right here and right now
(sorry!), and a few basically revealed people who've never to my
knowledge managed anything more complicated than a zippo lighter
claiming profound and intuitive insight into mass scalability.

But as I said it's a few RFCs short of an internet.

Just meant to stir some discussion: Is there life after IPv6? What
might motivate another round of evolution and by whom?

My sense is these questions might be more imminent than some may want
to believe given the rise of issues such as security, privacy,
government control, accountability, legal and insurance issues, and a
multi-trillion dollar economy riding on this internet little of which
was really on the table in, say, 1990.

For example given the relatively low adoption of IPv6 and the
impossibility (pretty much) of going forward with IPv4, and the new
realities I mention, might someone(s) with sufficient interest and
capitalization and influence push to knock over the whole game board?

They marched us into a box canyon!

-- 
-Barry Shein

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

Spoofer Report for NANOG for Sep 2019

[CAIDA Spoofer Project]

In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Sep 2019:
   ASN Name   Fixed-By
 13427 SOFTCOM-INTERNET-COMMUNICATION 2019-09-12
  3807 UMTNET-ASN 2019-09-16
  8047 GCI2019-09-16
   225 VIRGINIA   2019-09-18
 16787 CHARTER-16787-DC   2019-09-23
 22402 NEXTCO 2019-09-23
  2828 XO-AS152019-09-26

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Sep 2019:
   ASN Name   First-Spoofed Last-Spoofed
 40065 CNSERVERS 2016-05-01   2019-09-04
   209 CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2019-09-25
  6128 CABLE-NET-1   2016-09-03   2019-09-25
 27364 ACS-INTERNET  2016-09-27   2019-09-19
 20412 CLARITY-TELECOM   2016-09-30   2019-09-27
  6181 FUSE-NET  2016-10-10   2019-09-29
 15305 SYRINGANETWORKS   2016-10-21   2019-09-19
 14971 PINETEL   2016-10-21   2019-09-19
 25787 ROWE-NETWORKS 2016-10-21   2019-09-29
   174 COGENT-1742016-10-21   2019-09-26
 32440 LONI  2016-11-03   2019-09-26
 12083 WOW-INTERNET  2016-11-09   2019-09-30
 39939 RISE-CO-AS39939   2016-11-11   2019-09-12
  1403 EBOX  2016-11-12   2019-09-27
  2828 XO-AS15   2016-11-21   2019-09-11
  9009 M247  2017-01-10   2019-09-04
   701 UUNET 2017-06-14   2019-09-30
 63296 AMARILLO-WIRELESS 2017-09-01   2019-09-27
   546 PARSONS-PGS-1 2017-11-20   2019-09-12
 54540 INCERO-HVVC   2018-01-15   2019-09-16
 1 AKAMAI2018-02-14   2019-09-30
  4201 ORST  2018-04-19   2019-09-25
 11827 WSU   2018-05-07   2019-09-26
 19016 WCG   2018-05-19   2019-09-01
   225 VIRGINIA  2018-06-18   2019-09-27
 33452 RW2018-09-19   2019-09-28
 20448 VPNTRANET-LLC 2018-09-20   2019-09-10
 63275 RADIOWIRE 2019-02-07   2019-09-23
 15290 ALLST-15290   2019-04-09   2019-09-19
  8047 GCI   2019-04-11   2019-09-24
 10745 ARIN-ASH-CHA  2019-04-29   2019-09-30
 38235 MEKONGNET-ADC 2019-05-09   2019-09-22
32 STANFORD  2019-08-21   2019-09-24
 21709 IMPLEX-NET2019-09-24   2019-09-24

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Please send any feedback or suggestions to spoofer-i...@caida.org

Telemetry System Ideas

[Chris Misa]

I am a researcher working on developing a new on-the-fly telemetry 
system that potentially takes a flow chart as input to describe a 
particular detection task (rather than just features or information 
elements as in IPFIX). For an example of what I mean by "flow chart" see 
the figure here: 
https://ieeexplore.ieee.org/mediastore_new/IEEE/content/media/8048782/8048856/8048939/8048939-fig-4-source-hires.gif.


Might anyone have pointers to a source of more such flow charts?

The other issue I'm worried about is that it might take a couple rounds 
before an event is detected (since the system has to step through the 
flow chart and possibly look at different traffic features in the 
process). What is a typical duration of the types of events people might 
want to catch with a telemetry system like this? Do these kind of events 
generate the same type of traffic throughout their durations, or do 
traffic features change as the event progresses?


Thanks!

Chris

RE: worse than IPv6 Pain Experiment

[Kevin Menzel]

> Bits is bits.

A fixed length bit field and a variable length bit field are incredibly 
different beasts at the hardware level. Knowing exactly after how many bits you 
can make a routing or switching decision is ... pretty darned useful.

Kevin Menzel
Infrastructure Analyst
Sheridan College

-Original Message-
From: NANOG  On Behalf Of b...@theworld.com
Sent: Wednesday, October 9, 2019 5:43 PM
To: John Levine 
Cc: nanog@nanog.org; b...@theworld.com
Subject: Re: worse than IPv6 Pain Experiment


OK OK OK.

Can I summarize the current round of objections to my admittedly off-beat 
proposal (use basically URLs rather than IP addresses in IP packet src/dest) as:

  We can't do that! It would require changing something!

I've no doubt many here are comfortable with the current architecture.

Bits is bits.

URLs are, to a machine, just bit strings though they do incorporate a 
hierarchical structure which isn't that dissimilar from current network/host 
parts of IP addresses.

URLs are an obvious candidate to consider because they're in use, seem to 
basically work to identify routing endpoints, and are far from a random, out of 
thin air, choice.

Given the vast improvements in hardware since we last seriously thought about 
this (ca. 1990, IPv6) perhaps this worship of bit-twiddling and bit-packing may 
be a bit (haha) like those who once objected to anything but machine language 
programming because HLLs were so inefficient!

P.S. It was from a talk I gave in Singapore to the local HackerSpace and 
intended to provoke thought and discussion but not just "no, we can't do that 
because that's not the way we do things."

-- 
-Barry Shein

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

Re: Update to BCP-38?

[Mark Collins]

Any additional effort put in by an attacker will increase the chance of an 
attack being detected before it is successful. COnsider the following two 
scenerios.

Scenerio 1 is a webserver that makes no effort to obfuscate:

  1.  Attacker does HEAD request on /, which is a legitmate request, and sees 
the webserver vendor name
  2.  Attacker does a quick search, and finds there is a vulnerabilty in 
webserver
  3.  Attacker exploits vulnerability

Now, consider scenerio 2, where the server is configured to hide the webserver 
vendor and has an IDS/IPS system in place

  1.  Attacker does HEAD request on /, which is a legitmate request, but there 
is no usable information in the respone.
  2.  Attacker does a probe on the webserver to try a number of attacks, which 
generate a number of 403, 404, 500 etc errors in the webserver logs
  3.  IDS/IPS sees the sudden spike in errors from a single IP address and  
blocks the source IP

The act of obfuscation made it possible for the IDS/IPS to detect the probe, 
preventing the attack. WIll this block every attack? Probably not, but it 
increases the effectiveness of the security by forcing the attacker to take 
additional (detectable) actions when trying to break in.

The lock on your front door can be picked by anyone with a $10 lockpick set in 
under 5 minutes, does that mean you shouldn't bother locking your doors?

Mark

From: NANOG  on behalf of 
Keith Medcalf 
Sent: 08 October 2019 18:53
To: nanog@nanog.org 
Subject: RE: Update to BCP-38?


On Tuesday, 8 October, 2019 11:03, William Herrin  wrote:

>Limiting the server banner so it doesn't tell an adversary the exact OS-
>specific binary you're using has a near-zero cost and forces an adversary
>to expend more effort searching for a vulnerability. It doesn't magically
>protect you from hacking on its own. As you say, your security must not
>be breached just because the adversary figures out what version you're
>running. But viewed as one layer in an overall plan, limiting that
>information enhances your security at negligible cost. That's security
>smart.

I think your analysis is incorrect.

There are two cases which are relevant:
(1) The attack is non-targetted (that is, it is opportunistic)
(2) The attack is targetted at you specifically.

In the former (1) case, it does not matter whether the "banner" identifies the 
specific OS binary or not as it is irrelevant.  The script either works or it 
does not.  Even if the "banner" says "Beyond this point there be monsters" will 
make absolutely not one whit of difference.

In the latter (2) case, it does not matter whether the "banner" identifies the 
specific OS binary or not as it is irrelevant.  You have been targetted.  All 
possible exploits will be attempted until success is achieved or the vat of 
exploits to try runs dry.

So while the cost of doing the thing may be near-zero, it is not zero.  All 
those near-zero cost things you do that have no actual advantage can add up to 
quite a huge total and it will be more advantageous to spend that somewhere 
where it will, in fact, make a difference.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.



This Email from Marie Stopes International and any attachments may contain 
information which is privileged or confidential. It is meant only for the 
individual(s) or entity named above. If you are not the intended recipient(s) 
of this Email or any part of it please notify the sender immediately on receipt 
and delete it from your system. Any opinion or other information in this email 
or its attachments that does not relate to the business of Marie Stopes 
International is personal to the sender and is not given or endorsed by Marie 
Stopes International.

Re: Contact at DALnet?

[Mattias Ahnberg]

On 2019-10-09 10:59, Christopher Smalling wrote:

If someone from DALnet or someone with a contact at DALnet, please contact me 
off-list.

Hey Christopher,
thanks for the heads up. I've poked our networking team to look into it. DALnet 
is just an
IRC network so we're staffed by volunteers and its been low pace recently. Will 
ensure
that someone gets back to you shortly.
--
/ahnberg

Re: California public safety power shutdowns

[Michael Thomas]

On 10/10/19 10:40 AM, Randy Bush wrote:

Pacific Gas & Electric and Southern California Edison have started
Public Safety Power Shut-offs (PSPS) in California wildfire high-risk
areas.

not exactly

the diablo winds are way north in the state.  but much of the power
for the big metros is bought from the hydros in the northwest and
has to come on lines through the windy area.

for some years, pg traded short term profits for long term risk by
not clearing the lines.  their long term risk cost lives, jillions in
property and other damage last fire season.

now pg is in a severe liability pickle and madly trying to shovel
kitty litter over it.

the high risk is putting stockholders and profit before public safety
and service.

It's also pretty clear that this is revenge pr0n for us getting all 
upset for them burning down paradise.


I'm fairly certain that tech can help this problem along significantly, 
but that might cut into e-staff bonuses.



https://wildfiremitigation.tees.tamus.edu/faqs/other-monitoring-benefits


Mike

Re: California public safety power shutdowns

[Mel Beckman]

Sean,

You might be thinking of the Western U.S. Energy Crisis of 2000 and 2001, also 
known as the Enron Debacle. Indeed PG’s hands were tied via regulation while 
Enron, “The Smartest Guys in the Room”, cheated the market, electrical 
customers, and investors out of billions of dollars.

The crisis was triggered by partial deregulation legislation instituted in 1996 
by the California Legislature (AB 1890). Enron exploited this deregulation to 
steal wealth via economic withholding and inflated price bidding in 
California's spot markets. In the meantime, PG (and SCE) were still fully 
regulated, and thus unable to react.

An amazing NANOG irony from the Enron disaster was that Switch Networks in Las 
Vegas bought up the original Enron data center for pennies on the dollar. I 
became one of their earliest customers. Following Enron’s bankruptcy, Rob Roy 
bought Enron's mammoth (for the time) DC in an auction attended only by Rob, 
for less than a million bucks. Eventually Switch expanded to control the 
biggest data center complex in the world, and paved the way for companies like 
Google and Amazon to build their own hyperscale DCs.

 -mel

On Oct 10, 2019, at 9:53 AM, Michael Thomas 
mailto:m...@mtcc.com>> wrote:



On 10/9/19 2:15 PM, William Herrin wrote:
On Wed, Oct 9, 2019 at 12:37 PM Sean Donelan 
mailto:s...@donelan.com>> wrote:
Pacific Gas & Electric and Southern California Edison have started Public
Safety Power Shut-offs (PSPS) in California wildfire high-risk areas.

Wasn't California in a similar mess 20 years ago when government regulation at 
the time also put PG in the position that they couldn't deliver the 
electricity their customers wanted? Something to do with hard limits on what 
PG could do but few limits on what third parties could do to it.


No.

Mike

Regards,
Bill Herrin


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

Re: California public safety power shutdowns

[Randy Bush]

> Pacific Gas & Electric and Southern California Edison have started
> Public Safety Power Shut-offs (PSPS) in California wildfire high-risk
> areas.

not exactly

the diablo winds are way north in the state.  but much of the power
for the big metros is bought from the hydros in the northwest and
has to come on lines through the windy area.

for some years, pg traded short term profits for long term risk by
not clearing the lines.  their long term risk cost lives, jillions in
property and other damage last fire season.

now pg is in a severe liability pickle and madly trying to shovel
kitty litter over it.

the high risk is putting stockholders and profit before public safety
and service.

randy

Re: California public safety power shutdowns

[Michael Thomas]

On 10/9/19 2:15 PM, William Herrin wrote:
On Wed, Oct 9, 2019 at 12:37 PM Sean Donelan > wrote:


Pacific Gas & Electric and Southern California Edison have started
Public
Safety Power Shut-offs (PSPS) in California wildfire high-risk areas.


Wasn't California in a similar mess 20 years ago when government 
regulation at the time also put PG in the position that they 
couldn't deliver the electricity their customers wanted? Something to 
do with hard limits on what PG could do but few limits on what third 
parties could do to it.



No.

Mike



Regards,
Bill Herrin


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

Re: AWS issues with 172.0.0.0/12

[Javier J]

IPv6 all the things.

On Thu, Oct 10, 2019, 12:11 PM Neil Hanlon  wrote:

> RCN here in the greater Boston area does CGNAT inside 10.0.0.0/8. This
> doesn't surprise me.
> On Oct 10, 2019, at 11:27, Javier J  wrote:
>>
>> Very strange ATT would put end users on an RFC 1918 block unless they
>> were doing NAT to the end user.
>> If they were doing NAT, I would expect CGNAT in the 100.something or
>> other range.
>>
>>
>> On Thu, Oct 10, 2019, 11:07 AM Mehmet Akcin < meh...@akcin.net> wrote:
>>
>>> Yes
>>>
>>> On Wed, Oct 9, 2019 at 20:46 Javier J < jav...@advancedmachines.us>
>>> wrote:
>>>
 I'm just curious, was the ip in the RFC 1918 172.16.0.0/16 range?

 https://tools.ietf.org/html/rfc1918



 On Mon, Oct 7, 2019 at 6:01 PM Mehmet Akcin < meh...@akcin.net> wrote:

> To close the loop here (in case if someone has this type of issue in
> the future), I have spoken to AT instead of trying to work it out with
> AWS Hosted Vendor, Reolink.
>
> AT Changed my public IP, and now I am no longer in that 172.x.x.x
> block, everything is working fine.
>
> mehmet
>
> On Thu, Oct 3, 2019 at 2:54 PM Javier J < jav...@advancedmachines.us>
> wrote:
>
>> Auto generated VPC in AWS use RFC1819 addresses. This should not
>> interfere with pub up space.
>>
>> What is the exact issue? If you can't ping something in AWS chances
>> are it's a security group blocking you.
>>
>>
>>
>> On Tue, Oct 1, 2019, 7:00 PM Jim Popovitch via NANOG <
>> nanog@nanog.org> wrote:
>>
>>> On October 1, 2019 9:39:03 PM UTC, Matt Palmer < mpal...@hezmatt.org>
>>> wrote:
>>> >On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG
>>> >wrote:
>>> >> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
>>> >> > possible that this is various AWS customers making
>>> >iptables/firewall mistakes?
>>> >> >"block that pesky rfc1918 172/12 space!!"
>>> >>
>>> >> AWS also uses some 172/12 space on their internal network (e.g.
>>> the
>>> >network
>>> >> that sits between EC2 instances and the AWS external firewalls)
>>> >
>>> >Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
>>> >different
>>> >things, after all.
>>> >
>>>
>>> I don't know their entire operations, but they do use some
>>> 172.16.0.0/12
>>> addresses internally. And yes, that is very different than 172/12,
>>> sorry
>>> for the confusion.
>>>
>>> -Jim P.
>>>
>>> --
>>> Mehmet
>>> +1-424-298-1903
>>>
>>

Re: AWS issues with 172.0.0.0/12

[Neil Hanlon]

RCN here in the greater Boston area does CGNAT inside 10.0.0.0/8. This doesn't 
surprise me.

On Oct 10, 2019, 11:27, at 11:27, Javier J  wrote:
>Very strange ATT would put end users on an RFC 1918 block unless they
>were
>doing NAT to the end user.
>If they were doing NAT, I would expect CGNAT in the 100.something or
>other
>range.
>
>
>On Thu, Oct 10, 2019, 11:07 AM Mehmet Akcin  wrote:
>
>> Yes
>>
>> On Wed, Oct 9, 2019 at 20:46 Javier J 
>wrote:
>>
>>> I'm just curious, was the ip in the RFC 1918 172.16.0.0/16 range?
>>>
>>> https://tools.ietf.org/html/rfc1918
>>>
>>>
>>>
>>> On Mon, Oct 7, 2019 at 6:01 PM Mehmet Akcin 
>wrote:
>>>
 To close the loop here (in case if someone has this type of issue
>in the
 future), I have spoken to AT instead of trying to work it out
>with AWS
 Hosted Vendor, Reolink.

 AT Changed my public IP, and now I am no longer in that 172.x.x.x
 block, everything is working fine.

 mehmet

 On Thu, Oct 3, 2019 at 2:54 PM Javier J
>
 wrote:

> Auto generated VPC in AWS use RFC1819 addresses. This should not
> interfere with pub up space.
>
> What is the exact issue? If you can't ping something in AWS
>chances are
> it's a security group blocking you.
>
>
>
> On Tue, Oct 1, 2019, 7:00 PM Jim Popovitch via NANOG
>
> wrote:
>
>> On October 1, 2019 9:39:03 PM UTC, Matt Palmer
>
>> wrote:
>> >On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via
>NANOG
>> >wrote:
>> >> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
>> >> > possible that this is various AWS customers making
>> >iptables/firewall mistakes?
>> >> >"block that pesky rfc1918 172/12 space!!"
>> >>
>> >> AWS also uses some 172/12 space on their internal network
>(e.g. the
>> >network
>> >> that sits between EC2 instances and the AWS external
>firewalls)
>> >
>> >Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
>> >different
>> >things, after all.
>> >
>>
>> I don't know their entire operations, but they do use some
>> 172.16.0.0/12
>> addresses internally. And yes, that is very different than
>172/12,
>> sorry
>> for the confusion.
>>
>> -Jim P.
>>
>> --
>> Mehmet
>> +1-424-298-1903
>>

Re: California public safety power shutdowns

[Mel Beckman]

Electrical arcing happens around the country. The difference is that 
California, through years of unwise restrictions on vegetation control, has 
millions of acres of dry fuel near these powerlines.

In the early 1990s, a series of restrictions were placed on logging in the West 
to protect the Spotted Owl. As it turned out, nature was more complicated than 
expected, with owl numbers continuing to decline—even after the California 
timber harvest plummeted— reportedly due to predation from other raptors. It’s 
not easy to manipulate Mother Nature :)

In the meantime, tree harvests fell below the growth rate in the 1990s, to now 
one-tenth of what it was in 1988 on Federal lands. Thus the enormous spike in 
fuel, that is the primary driver behind the massive fires.

Those of us who operate data facilities, such as radio vaults, on California 
mountaintops, have dealt with this problem as a growing threat over decades. I 
have antennas with melted radomes just from the radiant fire heat a half mile 
away. We’re constantly fighting the government to control vegetation overgrowth 
around our sites, and are often prevented from doing so.

 -mel

On Oct 10, 2019, at 12:07 AM, Radu-Adrian Feurdean 
mailto:na...@radu-adrian.feurdean.net>> wrote:

On Thu, Oct 10, 2019, at 08:02, Mel Beckman wrote:

The fire risk is from electrical transmission lines, not from end users
of electrical power. The underlying problem is that the State’s rules
for line separation were ill-considered, making it possible for
high-enough winds to cause “line slapping” and the resultant arcing
that ignite fires.

There is no reason to think that end users are of any particular risk,
and fuel delivery during a preemptive outage wouldn’t be impaired,

That looks like a situation that you don't often encounter elsewhere (where 
electricity - distribution, telecom and transport are not very far from one 
another).

Re: AWS issues with 172.0.0.0/12

[Javier J]

Very strange ATT would put end users on an RFC 1918 block unless they were
doing NAT to the end user.
If they were doing NAT, I would expect CGNAT in the 100.something or other
range.


On Thu, Oct 10, 2019, 11:07 AM Mehmet Akcin  wrote:

> Yes
>
> On Wed, Oct 9, 2019 at 20:46 Javier J  wrote:
>
>> I'm just curious, was the ip in the RFC 1918 172.16.0.0/16 range?
>>
>> https://tools.ietf.org/html/rfc1918
>>
>>
>>
>> On Mon, Oct 7, 2019 at 6:01 PM Mehmet Akcin  wrote:
>>
>>> To close the loop here (in case if someone has this type of issue in the
>>> future), I have spoken to AT instead of trying to work it out with AWS
>>> Hosted Vendor, Reolink.
>>>
>>> AT Changed my public IP, and now I am no longer in that 172.x.x.x
>>> block, everything is working fine.
>>>
>>> mehmet
>>>
>>> On Thu, Oct 3, 2019 at 2:54 PM Javier J 
>>> wrote:
>>>
 Auto generated VPC in AWS use RFC1819 addresses. This should not
 interfere with pub up space.

 What is the exact issue? If you can't ping something in AWS chances are
 it's a security group blocking you.



 On Tue, Oct 1, 2019, 7:00 PM Jim Popovitch via NANOG 
 wrote:

> On October 1, 2019 9:39:03 PM UTC, Matt Palmer 
> wrote:
> >On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG
> >wrote:
> >> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
> >> > possible that this is various AWS customers making
> >iptables/firewall mistakes?
> >> >"block that pesky rfc1918 172/12 space!!"
> >>
> >> AWS also uses some 172/12 space on their internal network (e.g. the
> >network
> >> that sits between EC2 instances and the AWS external firewalls)
> >
> >Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
> >different
> >things, after all.
> >
>
> I don't know their entire operations, but they do use some
> 172.16.0.0/12
> addresses internally. And yes, that is very different than 172/12,
> sorry
> for the confusion.
>
> -Jim P.
>
> --
> Mehmet
> +1-424-298-1903
>

Re: AWS issues with 172.0.0.0/12

[Mehmet Akcin]

Yes

On Wed, Oct 9, 2019 at 20:46 Javier J  wrote:

> I'm just curious, was the ip in the RFC 1918 172.16.0.0/16 range?
>
> https://tools.ietf.org/html/rfc1918
>
>
>
> On Mon, Oct 7, 2019 at 6:01 PM Mehmet Akcin  wrote:
>
>> To close the loop here (in case if someone has this type of issue in the
>> future), I have spoken to AT instead of trying to work it out with AWS
>> Hosted Vendor, Reolink.
>>
>> AT Changed my public IP, and now I am no longer in that 172.x.x.x
>> block, everything is working fine.
>>
>> mehmet
>>
>> On Thu, Oct 3, 2019 at 2:54 PM Javier J 
>> wrote:
>>
>>> Auto generated VPC in AWS use RFC1819 addresses. This should not
>>> interfere with pub up space.
>>>
>>> What is the exact issue? If you can't ping something in AWS chances are
>>> it's a security group blocking you.
>>>
>>>
>>>
>>> On Tue, Oct 1, 2019, 7:00 PM Jim Popovitch via NANOG 
>>> wrote:
>>>
 On October 1, 2019 9:39:03 PM UTC, Matt Palmer 
 wrote:
 >On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG
 >wrote:
 >> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
 >> > possible that this is various AWS customers making
 >iptables/firewall mistakes?
 >> >"block that pesky rfc1918 172/12 space!!"
 >>
 >> AWS also uses some 172/12 space on their internal network (e.g. the
 >network
 >> that sits between EC2 instances and the AWS external firewalls)
 >
 >Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
 >different
 >things, after all.
 >

 I don't know their entire operations, but they do use some
 172.16.0.0/12
 addresses internally. And yes, that is very different than 172/12, sorry
 for the confusion.

 -Jim P.

 --
Mehmet
+1-424-298-1903

Re: worse than IPv6 Pain Experiment

[Tony Finch]

b...@theworld.com  wrote:
>
> Can I summarize the current round of objections to my admittedly
> off-beat proposal (use basically URLs rather than IP addresses in IP
> packet src/dest) as:

[snip]

This reminds me of the named data networking research project

https://named-data.net/project/faq/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Southwest 6
to gale 8, occasionally 5 at first, then veering west or northwest 3 to 5
later. Moderate or rough, occasionally very rough later in far south. Rain or
showers. Moderate or good, occasionally poor later.

Re: California public safety power shutdowns

[Radu-Adrian Feurdean]

On Thu, Oct 10, 2019, at 08:02, Mel Beckman wrote:

> The fire risk is from electrical transmission lines, not from end users 
> of electrical power. The underlying problem is that the State’s rules 
> for line separation were ill-considered, making it possible for 
> high-enough winds to cause “line slapping” and the resultant arcing 
> that ignite fires. 
> 
> There is no reason to think that end users are of any particular risk, 
> and fuel delivery during a preemptive outage wouldn’t be impaired, 

That looks like a situation that you don't often encounter elsewhere (where 
electricity - distribution, telecom and transport are not very far from one 
another).

Re: California public safety power shutdowns

[Sean Donelan]

On Thu, 10 Oct 2019, Radu-Adrian Feurdean wrote:
So, during a Power shut-off because of wild*fire* risk, operators are 
supposed to be able to re-charge batteries and supply generators with 
fuel (I suppose diesel, regular gas being even worse) in the affected 
areas ? Did I understand things wrong ?


I don't have an issue with shutting down power preventively in order to 
reduce an already high risk, but pretending that other people will keep 
their electricity-dependent equipment up, especially by providing 
flamable stuff - isn't this a huge WTF ?



The U.S. transmission grid is highly dependent on long-distance 
transmission wires passing through lots of dried out forests, brush, etc. 
The very high-voltage lines have clear-cut areas, the medium and lower 
voltages lines are less carefully maintained.


We love our cheap power generation plants in distant places, such as 
hydro-dams, large nuclear plants, wind and solar farms, and of course 
dirty-old coal plants in the desert far away from power consumers in 
cities and rural areas in between.  Yes, I know there are lots of 
proposals to re-invent the electric grid.


Many of the same reasons why Internet companies build big data 
centers in far away places?




The transmission lines also pass through a lot of difficult to reach and 
monitor terrain, so sparks and wildfires can get a big start before any 
response.  That's also why it will take days to turn the grid back on, 
because PG needs to inspect those lines to make sure they weren't 
damaged while powered down.


Damn squirriels and their gnawing teeth!



Small point power sources, such as tower site generators, are usually on 
non-flamable pads with cleared (gravel, etc) around them.  Different risk 
factors.


While wildfires have been started by things as simple as a driver pulling 
a hot car with a flat tire off the road into dry grass, wildfires caused 
by power transmission grid damage, malfunction and age are more common.


Hence liability judgements, bankruptcy proceedings, and so on...

Re: California public safety power shutdowns

[Mel Beckman]

Radu,

The fire risk is from electrical transmission lines, not from end users of 
electrical power. The underlying problem is that the State’s rules for line 
separation were ill-considered, making it possible for high-enough winds to 
cause “line slapping” and the resultant arcing that ignite fires. 

There is no reason to think that end users are of any particular risk, and fuel 
delivery during a preemptive outage wouldn’t be impaired, because roads will 
remain open. So, nobody need pretend anything. It’s just business as usual, 
until a fire actually starts.

 -mel 

> On Oct 9, 2019, at 10:52 PM, Radu-Adrian Feurdean 
>  wrote:
> 
>> On Wed, Oct 9, 2019, at 22:26, Sean Donelan wrote:
>> 
>> - Will this affect cellphone service?
>> 
>> Generally no because this is a power shutoff, without other disaster 
>> damage.  All major switching offices have backup generators for 24 
>> to 72 hours and nearly all cell towers and outside plant have backup 
>> batteries for 4 to 8 hours and/or backup generators.  Service providers 
>> should be able to re-charge batteries and refill generator tanks 
>> throughout the power shut-off.  Of course, if there is some other disaster 
>> during this time, there would be less resiliance in the network.
> 
> In a Previous e-mail:
> 
>> Public Safety Power Shut-offs (PSPS) in California wildfire high-risk areas.
> 
> So, during a Power shut-off because of wild*fire* risk, operators are 
> supposed to be able to re-charge batteries and supply generators with fuel (I 
> suppose diesel, regular gas being even worse) in the affected areas ? Did I 
> understand things wrong ?
> 
> I don't have an issue with shutting down power preventively in order to 
> reduce an already high risk, but pretending that other people will keep their 
> electricity-dependent equipment up, especially by providing flamable stuff - 
> isn't this a huge WTF ?