Re: Northern Virginia has had enough with data centers

[Joel Halpern]

I will note that the grid in Loudoun county (arguably the center of the 
Northern Virginia data center boom) has actually gotten a LOT better 
than it was when I first moved here.  Some of that was rebuild started 
before the surge, due to just how bad it was.  But I am fairly sure that 
some of it is a side-effect of the build itself.


Yours,

Joel

On 6/23/2023 6:17 PM, Sean Donelan wrote:


Northern Virginia has about 275 data centers

The noise complaints are about HVAC fan noise (24-hour droning) from 
cooling towers or roof top farms of evaporative condensers.


The water complaints are about the one-use water cooling towers

The electric grid complaints are about the demand on the grid making 
the entire region less stable and proposed construction of new 
high-voltage tower corridors for data centers.


And if you didn't know, some VC-funded companies can be a**-holes and 
not known for being good neighbors or anything besides making money.


And yes, I helped design & build several early data centers in NOVA :-)

https://www.washingtonpost.com/dc-md-va/2023/02/10/data-centers-northern-virginia-internet/ 

Re: [EXTERNAL] Re: BCP38 For BGP Customers

[Joel Halpern]

The Internet Draft is at: 
https://datatracker.ietf.org/doc/html/draft-sriram-sidrops-bar-sav-01


Some slides that will be used to present thematerial on Friday are 
at:https://datatracker.ietf.org/meeting/115/materials/slides-115-savnet-lowering-improper-block-and-improper-admit-for-sav-the-bar-sav-approach


On 11/8/2022 12:17 PM, Compton, Rich A wrote:

Hi Joel, can you please point us to the IETF draft document that describes how a 
"combination of ASPA and RPKI can be used to help with DDoS prevention".  I was 
not able to find it.
Thanks!
-Rich

On 11/8/22, 8:05 AM, "NANOG on behalf of Joel Halpern"j...@joelhalpern.com>  wrote:


 CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

 There is work a tthe IETF on an addon to RPKI called ASPA.  There is a
 draft that describes how the combiantion of ASPA and RPKI can be used to
 help with DDOS prevention.

 There is also a working group at the IETF called SAVNET that is looking
 at what technological additions can be made to address the shortcomings
 in BCP 38.  In fairness, there is distinct disagreement as to what those
 shortcomings are, and whether the ideas being presented can help.  Input
 from more operators would be great.  (For completeness, I am a co-chair
 of that working group.)

 Yours,

 Joel

 On 11/8/2022 9:39 AM, Brian Turnbow via NANOG wrote:
 > Hi Mike
 >
 >
 >
 >> This may not exist yet, but what about a uRPF-like feature that uses 
RPKI, IRR, etc. instead of current BGP feed?
 >
 > There is rfc8704 that extends urpf
 > But I do not know of any commercial available solutions
 >
 >
 > Brian

E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: BCP38 For BGP Customers

[Joel Halpern]

There is work a tthe IETF on an addon to RPKI called ASPA.  There is a 
draft that describes how the combiantion of ASPA and RPKI can be used to 
help with DDOS prevention.


There is also a working group at the IETF called SAVNET that is looking 
at what technological additions can be made to address the shortcomings 
in BCP 38.  In fairness, there is distinct disagreement as to what those 
shortcomings are, and whether the ideas being presented can help.  Input 
from more operators would be great.  (For completeness, I am a co-chair 
of that working group.)


Yours,

Joel

On 11/8/2022 9:39 AM, Brian Turnbow via NANOG wrote:

Hi Mike




This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR, 
etc. instead of current BGP feed?


There is rfc8704 that extends urpf
But I do not know of any commercial available solutions


Brian

Re: Outbound Route Filtering (ORF) vendor support

[Joel Halpern]

You may want to examine the IDR lsit archive
https://mailarchive.ietf.org/arch/browse/idr/?q=orf
for discussion of the orf proposal and the difficulties people have with it.

Yours,
Joel

On 8/18/2021 1:10 PM, Douglas Fischer wrote:

Hello!

I also found a recent draft(expires Novembre 2021) about using Route 
Distinguisher as a Value on ORF.
https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/ 






Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza 
mailto:humbertogal...@gmail.com>> escreveu:


Hi,

Is anyone aware of any vendor that supports Outbound Route Filtering
(ORF) based on anything other than prefix-lists?

I found these two old IETF drafts (both expired :-/) which supported
the idea of filtering based on community and as-path respectively, but
I wasn't able to understand if they were ever discussed at the WG and
if there was any outcome of the discussion (I suspect the authors are
no longer even working with the mentioned companies in the drafts):

-
https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02

- https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13


Any info is very much appreciated.

Thanks,



--
Douglas Fernando Fischer
Engº de Controle e Automação

Re: understanding IPv6

[Joel Halpern]

Just to clarify context, at this stage this is just Pascal's interesting 
idea for how to make ND work better on wireless.  No IETF working group 
has adopted this.  Various people seem to be interested, but it will be 
some time before we know if his approach gets traction.


The biggest difference between this and earlier changes along this line 
is that the wireless broadcast problem provides motivation for the 
change, where earlier efforts were more ~wouldn't it just be simpler if...~


Yours,
Joel Halpern

On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote:
What I'm amazed at is the concept of multi-link subnet and the change in 
IP model being proposed.


See, for example, section 4 of 
https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05


Has anyone felt the same about the change being proposed? This swept 
away 25 years of thinking about IP subnets and IP links for me.


Etienne

On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin <mailto:lists.na...@monmotha.net>> wrote:


On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote:
 > There are very interesting and unobvious moments on IPv4 vs IPv6,
for
 > example related to battery lifetime in embedded electronics. In
ipv4,
 > many devices are forced to send "keepalives" so that the NAT
entry does
 > not disappear, with IPv6 it is not required and bidirectional
 > communications possible at any time. And in fact, it has a huge
impact
 > on the cost and battery life of IoT devices.
 > When I developed some IoT devices for clients, it turned out that if
 > "IPv6-only" is possible, this significantly reduces the cost of the
 > solution and simplify setup.

This is difficult to understate.  "People" are continually amazed
when I
show them that I can leave TCP sessions up for days at a time (with
properly configured endpoints) with absolutely zero keepalive traffic
being exchanged.

As amusingly useful as this may be, it pales in comparison to the
ability to do the same on deeply embedded devices running off small
primary cell batteries.  I've got an industrial sensor network product
where the device poll interval is upwards of 10 minutes, and even then
it only turns on its receiver.  The transmitter only gets lit up about
once a day for a "yes I'm still here" notification unless it has
something else to say.

In the end, we made it work across IPv4 by inserting an application
level gateway.  We just couldn't get reliable, transparent IPv6
full-prefix connectivity from any of the cellular telematics providers
at the time.  I don't know if this has changed.  For our application,
this was fine, but for mixed vendor "IoT" devices, it would probably
not
work out well.
-- 
Brandon Martin




--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: IPv6 Pain Experiment

[Joel Halpern]

Folks should be aware that if you do not assume extreme pressure (which 
is what it is taking to get IPv6 deployed), it turns out to be quite 
hard to get the deployment incentives and structures for a 
map-and-encaps scheme to actually work for Internet-wide deployment.  It 
does work for a range of special cases.


Yours,
Joel

On 10/7/2019 10:58 PM, Michel Py wrote:

William Herrin wrote :
I was out to prove a point. I needed a technique that, at least in theory, 
would start working as a result of software
  upgrades alone, needing no configuration changes or other operator 
intervention. If I couldn't do that, my debate
opponent was right -- a greenfield approach to IPv6 made more sense despite the 
deployment challenge.


I think that, 12 years ago, you had the best mouse trap.


Map-encap, where you select a decapsulator (consult the map) and then send a 
tunneled packet (encapsulated) does
some cool stuff, but it's a pretty significant change to the network 
architecture. Definitely not configuration-free.


I am so painfully aware of this.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: Stupid Question maybe?

[Joel Halpern]

History of non-contiguous network masks, as I observed it.

The rules did not prohibit discontiguous network masks.  But no one was 
sure how to make them work.  In particular, how to allocate subnets from 
discontiguous networks in a sensible fashion.


In the early 90s, during the efforts to solve the swamp and classful 
exhaustion problems, Paul Francis (then Tsuchia) and I each worked out 
table structures that would allow for discontiguous masks with 
well-defined "prefixes" / "parents".  Both approaches were based on 
extensions of Knuth's Patricia trees.  (It took some interesting 
analysis and extensions.)


When we were done, other folks looked at the work (I don't know if the 
Internet Drafts are still in repositories, but they shoudl be.)  And 
concluded that while this would work, no network operations staff would 
ever be able to do it correctly.  So as a community we decided not to go 
down that path.


Yours,
Joel

On 12/18/18 5:12 PM, David Edelman wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I seem to remember that before the advent of VLSM and CIDR there was no 
requirement for the 1 bits in the netmask to be contiguous with no intervening 
0 bits and there was always someone who tested it out on a production network 
just to prove a point (usually only once)

Dave

- -Original Message-
From: NANOG  On Behalf Of Naslund, Steve
Sent: Tuesday, December 18, 2018 3:37 PM
To: nanog@nanog.org
Subject: RE: Stupid Question maybe?

It is a matter of machine readability vs human readability.  Remember the IP 
was around when routers did not have a lot of horsepower.  The dotted decimal 
notation was a compromise between pure binary (which the equipment used) and 
human readability.  VLSM seems obvious now but in the beginning organizing 
various length routes into very expensive memory and low horsepower processors 
meant that it was much easier to break routes down along byte boundaries.  This 
meant you only had four different lengths of route to deal with.  It was 
intended to eliminate multiple passes sorting the tables.  I am not quite sure 
what you mean about interspersing zeros, that would be meaningless.  Remember 
that it is a mask.  The address bits which are masked as 1s are significant to 
routing.  The bits that are masked with 0s are the host portion and don't 
matter to the network routing table.

Steven Naslund
Chicago IL



/24 is certainly cleaner than 255.255.255.0.

I seem to remember it was Phil Karn who in the early 80's suggested that 
expressing subnet masks as the number of bits from the top end of the address word 
was efficient, since subnet masks were always a series of ones followd >by 
zeros with no interspersing, which was incorporated (or independently invented) 
about a decade later as CIDR a.b.c.d/n notation in RFC1519.
- Brian

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBlw1AAKCRCXCCyZOY1F
IYkTAJ98Gh+IGhDcyIB92H9JyWtbCVDhugCfZXq60pnHCqttKfw2fpUCBagTxYo=
=RimM
-END PGP SIGNATURE-