Re: AW: Cogent - Google - HE Fun

[Jon Lewis]

On Thu, 10 Mar 2016, William Herrin wrote:


It's Cogent's fault because: double-billing. Google should not have to
pay Cogent for a service which you have already paid Cogent to provide
to you. Cogent's demand is unethical. They intentionally fail to
deliver on the basic service expectation you pay them for and refuse
to do so unless a third party to your contract also pays them.


That's one way of looking at it.

However, which of your transits don't bill for bits exchanged with other 
customers of theirs...and how are they or you accounting for that traffic?


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: AW: Cogent - Google - HE Fun

[Dave Bell]

On 10 March 2016 at 15:55, William Herrin  wrote:
> It's Cogent's fault because: double-billing. Google should not have to
> pay Cogent for a service which you have already paid Cogent to provide
> to you. Cogent's demand is unethical. They intentionally fail to
> deliver on the basic service expectation you pay them for and refuse
> to do so unless a third party to your contract also pays them.
>
> Google, by contrast, makes no demand that Cogent pay them even though
> you are not paying Google for service. They offer "open peering," a
> free interconnect via many neutral data centers.

I don't get this. Google are basically a hosting provider. If I set up
my own website, I would expect to have to pay transit for it. If I ran
a hosting business I would expect to pay transit. Why are google
different?

Its Google's decision to decide not to pay for transit for v6.
Considering how open they are to peering, and how large their network
it, it probably makes a lot of sense. If you need to connect to a
transit provider, you can probably peer with google at the same
location.

Cogent is in the business of trying to provide transit. I understand
there are probably good business cases where you may want to set up an
SFI with someone like google, but at the end of the day that's their
choice.

I get the arguments that Cogent are supposed to be supplying a full
view of the DFZ, but if Joe's Hosting Company refuses to pay anyone
for transit, surely it is their own fault that their reachability is
compromised?

Regards,
Dave

Re: AW: Cogent - Google - HE Fun

[William Herrin]

On Fri, Mar 11, 2016 at 7:40 AM, Jon Lewis  wrote:
> On Thu, 10 Mar 2016, William Herrin wrote:
>> It's Cogent's fault because: double-billing. Google should not have to
>> pay Cogent for a service which you have already paid Cogent to provide
>> to you. Cogent's demand is unethical. They intentionally fail to
>> deliver on the basic service expectation you pay them for and refuse
>> to do so unless a third party to your contract also pays them.
>
> That's one way of looking at it.
>
> However, which of your transits don't bill for bits exchanged with other
> customers of theirs...and how are they or you accounting for that traffic?

Hi Jon,

As you know, there is a technology limitation in how routing works
which says that for any given block of addresses you can, absent
extraordinary measures, have a peering relationship or a transit
relationship but not both. If both parties choose to have a transit
relationship, that excludes a peering relationship for the relevant
blocks of addresses. And that's OK when _both sides_ choose it.

In related news, no ethical conundrum demands defiance of the law of gravity.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: AW: Cogent - Google - HE Fun

[Mikael Abrahamsson]

On Fri, 11 Mar 2016, Dave Bell wrote:

I don't get this. Google are basically a hosting provider. If I set up 
my own website, I would expect to have to pay transit for it. If I ran a 
hosting business I would expect to pay transit. Why are google 
different?


If you had presence all across the world and were providing a sizable 
chunk of the world total traffic, you would probably reason differently.


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

RE: Cogent - Google - HE Fun

[Robert Jacobs]

Don't like what Cogent is doing but just to bring this back to reality Matthew 
and others out there... What content do you think Google has or any other big 
content provider that is IPV6 only or gives an IPV6 only response to a query 
from Cogent that would not work via normal IPV4 routes and IP's.. Till we have 
exclusive content on IPV6 or it is a shorter, faster, bigger, better path then 
we are still fighting this uphill battle to get more adoption of IPV6 and it 
will not matter to the majority of Cogent customers that they can't get full 
IPV6 routes and connections from Cogent.

Robert Jacobs | Network Architect Director

Direct:  832-615-7742
Main:   832-615-8000
Fax:713-510-1650

5959 Corporate Dr. Suite 3300; Houston, TX 77036



 

 

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matthew D. Hardeman
Sent: Thursday, March 10, 2016 4:54 PM
To: Mark Andrews 
Cc: North American Network Operators' Group 
Subject: Re: Cogent - Google - HE Fun

Mark,

I certainly agree that intentional harm of a purely malicious nature is to be 
discouraged.

What I proposed, as an alternative to some of the more extreme mechanisms being 
discussed, is a mechanism whereby IPv6 _customers_ of Cogent transit 
services--and who also receive IPv6 transit from at least one other 
relationship--can modify their IPv6 advertisements to Cogent such that they 
utilize that transit link with Cogent for the one thing you can reliably count 
on it for in the IPv6 world: reaching other Cogent IPv6 customers, especially 
the single-homed ones.

In essence, adding BGP community “174:3000” to your IPv6 advertisements to 
Cogent instructs Cogent that this route should only be advertised internal to 
Cogent and to Cogent’s customers.  It should not be announced to peers.  
Combining that with prepends of your own AS in the IPv6 advertisements to 
Cogent also reduces traffic from other multi-homed Cogent IPv6 customers.  In 
any event, if enough Cogent customers do this, it does greatly reduce the 
amount of traffic that Cogent gets to transit from their various IPv6 peers 
while still avoiding harm to innocent end-users (or for that matter, to guilty 
end users).

The mechanism I proposed has numerous benefits:

1.  It utilizes only a mechanism created by Cogent and documented for use by 
Cogent transit customers to achieve routing policy that benefits IPv6 customers 
of Cogent.
2.  It causes no harm to single-homed Cogent customers.
3.  It causes no direct harm to Cogent.  The sole indirect harm that it might 
bring upon Cogent if adopted en-masse would be to significantly drop the amount 
of traffic crossing Cogent’s SFI peerings on IPv6, which I acknowledge may have 
consequences for Cogent.  If it did have such consequences, it’s Cogent’s game 
and Cogent’s rules.  They could change it any time.  If it indirectly harms 
Cogent by lowering overall traffic volume on paid multi-homed customer transit 
connections, Cogent could easily remedy that by becoming an IPv6 network that 
one would want to exchange IPv6 transit traffic with rather than being an IPv6 
network that one begrudgingly pays because one does business with others who 
are Cogent single-homed.

I do reiterate, however, that I would strongly discourage any kind of routing 
tricks that leave the innocent Cogent customers out in the cold.  That hurts 
those Cogent customers as well as you and/or your own customers and users.  
Please, someone, think of the end-users here.

My advice to Cogent would be to remember something real simple:  When Big Boss 
#1 at RandomCorp has no trouble reaching Google services all night every night 
at home and then he comes to work and his office Internet does everything but 
Google….  What he’ll remember is “Charter works with Google, whoever we’re 
using at the office doesn’t.  Let’s switch.”  It’s shocking to me that an ISP 
with a retail segment thinks you can survive if Google doesn’t work, no matter 
what Google did to ensure it played out that way.  Frankly, Google could scream 
that they cut Cogent off because they didn’t like Cogent’s face and no one at 
retail would care.  They just want their Gmail back.  If Google wanted to force 
the issue faster, they could just stop the IPv4 transit routes to Cogent.  I 
think they’re taking a more balanced and conservative approach though.

Thanks,

Matt Hardeman

> On Mar 10, 2016, at 4:29 PM, Mark Andrews  wrote:
> 
> 
> I don't think anyone should be colluding to hurt Cogent or anyone
> else for that matter and this thread appears to be heading in this
> direction.
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Cogent - Google - HE Fun

[Christopher Morrow]

On Fri, Mar 11, 2016 at 10:18 AM, Robert Jacobs  wrote:
> Don't like what Cogent is doing but just to bring this back to reality 
> Matthew and others out there... What content do you think Google has or any 
> other big content provider that is IPV6 only or gives an IPV6 only response 
> to a query from Cogent that would not work
via normal IPV4 routes and IP's.. Till we have exclusive content on
IPV6 or it is a shorter,

it's not relevant (really) that 'you can still get there over v4',
because if your clients have ipv6, they'll ask for both, not
everything happy-eyeballs it's way to success, so
timeouts/frustration/pain occur.

I bet that's where the OP's original questions stem.

-chris

Verizon Voice Engineering Contact?

[chris]

Anyone from Verizon on the voice side on the list or if anyone has any good
contacts they can share?

We have customers in LATA 224 who cannot complete calls to a common carrier
and are hearing an audible verizon message "we're sorry all circuits are
busy now"

Please contact offlist

Thanks
chris

Re: Cogent - Google - HE Fun

[Jay R. Ashworth]

- Original Message -
> From: "Mark Andrews" 

> I don't think anyone should be colluding to hurt Cogent or anyone
> else for that matter and this thread appears to be heading in this
> direction.

I suspect a distinction could be made in court by a competent attorney between

"colluding to hurt Cogent"

and

"collaborating to keep Cogent's ill-chosen policies from hurting the utility 
of the greater Internet".

The Law does not guarantee *any* business the unsullied right to conduct its
business in any particular way and expect that always to work; companies
much newer than buggy-whip manufacturers have long since learned that.

[ I am not an attorney; if my advice breaks something, you get to keep both 
pieces. ]

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

Why the US Government has so many data centers

[Sean Donelan]

If you've wondered why the U.S. Government has so many data centers, ok I 
know no one has ever asked.


The U.S. Government has an odd defintion of what is a data center, which
ends up with a lot of things no rational person would call a data center.

If you call every room with even one server a "data center," you'll end up 
with tens of thousands of rooms now data centers.  With this defintiion, I 
probably have two data centers in my home.  Its important because 
Inspectors General auditors will go around and count things, because 
that's what they do, and write reports about insane numbers of data 
centers.



https://datacenters.cio.gov/optimization/

"For the purposes of this memorandum, rooms with at least one server, 
providing services (whether in a production, test, stage, development, or 
any other environment), are considered data centers. However, rooms 
containing only routing equipment, switches, security devices (such as 
firewalls), or other telecommunications components shall not be considered 
data centers."

Re: Why the US Government has so many data centers

[Roland Dobbins]

On 12 Mar 2016, at 0:03, Sean Donelan wrote:

The U.S. Government has an odd defintion of what is a data center, 
which ends up with a lot of things no rational person would call a 
data center.


There's also a case to be made that governmental organizations really 
oughtn't to have servers just lying around in random rooms, and that 
those rooms are de facto government data centers, whether those who're 
responsible for said rooms/servers know it or not . . .


---
Roland Dobbins 

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 12 Mar, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  586718
Prefixes after maximum aggregation (per Origin AS):  215597
Deaggregation factor:  2.72
Unique aggregates announced (without unneeded subnets):  285921
Total ASes present in the Internet Routing Table: 53056
Prefixes per ASN: 11.06
Origin-only ASes present in the Internet Routing Table:   36592
Origin ASes announcing only one prefix:   15789
Transit ASes present in the Internet Routing Table:6412
Transit-only ASes present in the Internet Routing Table:167
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  39
Max AS path prepend of ASN ( 40285)  34
Prefixes from unregistered ASNs in the Routing Table:  1062
Unregistered ASNs in the Routing Table: 367
Number of 32-bit ASNs allocated by the RIRs:  13030
Number of 32-bit ASNs visible in the Routing Table:   10052
Prefixes from 32-bit ASNs in the Routing Table:   39223
Number of bogon 32-bit ASNs visible in the Routing Table:15
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:345
Number of addresses announced to Internet:   2808944324
Equivalent to 167 /8s, 109 /16s and 22 /24s
Percentage of available address space announced:   75.9
Percentage of allocated address space announced:   75.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.0
Total number of prefixes smaller than registry allocations:  192220

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   150355
Total APNIC prefixes after maximum aggregation:   41706
APNIC Deaggregation factor:3.61
Prefixes being announced from the APNIC address blocks:  160207
Unique aggregates announced from the APNIC address blocks:64684
APNIC Region origin ASes present in the Internet Routing Table:5153
APNIC Prefixes per ASN:   31.09
APNIC Region origin ASes announcing only one prefix:   1192
APNIC Region transit ASes present in the Internet Routing Table:905
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 39
Number of APNIC region 32-bit ASNs visible in the Routing Table:   1931
Number of APNIC addresses announced to Internet:  753310980
Equivalent to 44 /8s, 230 /16s and 157 /24s
Percentage of available APNIC address space announced: 88.0

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 131072-135580
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:179827
Total ARIN prefixes after maximum aggregation:2
ARIN Deaggregation factor: 2.02
Prefixes being announced from the ARIN address blocks:   184828
Unique aggregates announced from the ARIN address blocks: 87774
ARIN Region origin ASes present in the Internet Routing Table:16409
ARIN Prefixes per AS

Re: Why the US Government has so many data centers

[Christopher Morrow]

On Fri, Mar 11, 2016 at 12:21 PM, Roland Dobbins  wrote:
> On 12 Mar 2016, at 0:03, Sean Donelan wrote:
>
>> The U.S. Government has an odd defintion of what is a data center, which
>> ends up with a lot of things no rational person would call a data center.
>
>
> There's also a case to be made that governmental organizations really
> oughtn't to have servers just lying around in random rooms, and that those
> rooms are de facto government data centers, whether those who're responsible
> for said rooms/servers know it or not . . .


because  at least:
  o safe handling of media is important (did the janitor just walk off
with backup tapes/ disks/etc?)
  o 'a machine under your desk' is not a production operation.
 (if you think it is, please stop, think again and move that
service to conditioned power/cooling/ethernet)

I'm sure there are other reasons, but honestly those 2 are great starters...

Re: Why the US Government has so many data centers

[Nick Hilliard]

Christopher Morrow wrote:
> because  at least:
>   o safe handling of media is important (did the janitor just walk off
> with backup tapes/ disks/etc?)
>   o 'a machine under your desk' is not a production operation.
>  (if you think it is, please stop, think again and move that
> service to conditioned power/cooling/ethernet)
> 
> I'm sure there are other reasons, but honestly those 2 are great starters...

The alternative may be:

- issue RFT for hosting / colocation facilities + high speed resilient
connectivity between colo and local network + associated equipment to
make this work, or

- building out enterprise-grade comms room in local office

This can be hard for public sector bodies to do and depending on the
value of the data hosting or the amount of kit that needed to be hosted,
it may also not be easy to justify.

Nick

Re: Cogent - Google - HE Fun

[Owen DeLong]

> On Mar 11, 2016, at 04:57 , Dave Bell  wrote:
> 
> On 10 March 2016 at 15:55, William Herrin  wrote:
>> It's Cogent's fault because: double-billing. Google should not have to
>> pay Cogent for a service which you have already paid Cogent to provide
>> to you. Cogent's demand is unethical. They intentionally fail to
>> deliver on the basic service expectation you pay them for and refuse
>> to do so unless a third party to your contract also pays them.
>> 
>> Google, by contrast, makes no demand that Cogent pay them even though
>> you are not paying Google for service. They offer "open peering," a
>> free interconnect via many neutral data centers.
> 
> I don't get this. Google are basically a hosting provider. If I set up
> my own website, I would expect to have to pay transit for it. If I ran
> a hosting business I would expect to pay transit. Why are google
> different?

No matter what kind of business I build, I don’t expect to pay transit
unless I am asking you to deliver packets to people who are not already
paying you.

Yes, if I make that request, I may also be paying transit for packets that
go to some or all of the users that are already paying you, but I would
expect in most cases, that is an artifact.

If I have content that your paying customers want and your paying customers
have enough demand for my content that it would fill one or more
interconnection-sized pipes (whatever your standard minimum interconnect
is, be that 1G, 10G, 100G, etc.), then I think it is reasonable to ask
for settlement free peering to reach those customers. If there isn’t
enough demand from your customers to justify that, then there are a few
other possibilities… Exchange points in common and public peering,
I give up on those customers, or, I pay you (or someone else) for transit.

I’m pretty sure in the case of Cogent<->Google the traffic level more than
justifies a reasonable number of PNIs in a diversity of locations.
 
> Its Google's decision to decide not to pay for transit for v6.
> Considering how open they are to peering, and how large their network
> it, it probably makes a lot of sense. If you need to connect to a
> transit provider, you can probably peer with google at the same
> location.

Depends on how you connect to said transit provider, but yeah, you can
either peer with Google yourself, or, you should be able to expect that
anyone you are paying for transit peers with Google as part of providing
you transit service to “the internet”.

It’s very hard to make a case that “Internet Access” can be sold if that
doesn’t include access to Google.

> Cogent is in the business of trying to provide transit. I understand
> there are probably good business cases where you may want to set up an
> SFI with someone like google, but at the end of the day that's their
> choice.

Sure, it’s their choice, but in so doing, there’s a valid case to be
made that they are not providing the contracted service to their transit
customers.

I don’t think anyone is saying “Cogent can’t do this”. I think we are
saying “Cogent’s customers may want to consider their rights and their
contracts with Cogent in this process.”

> I get the arguments that Cogent are supposed to be supplying a full
> view of the DFZ, but if Joe's Hosting Company refuses to pay anyone
> for transit, surely it is their own fault that their reachability is
> compromised?

Yes and no… How many of the Alexa 10, 50, 100, 500, 1000 are hosted
at Joe’s?

I think those numbers are a bit different from Google and like it or not,
there’s meaning to that.

Owen

Re: Cogent - Google - HE Fun

[Owen DeLong]

> On Mar 11, 2016, at 06:16 , William Herrin  wrote:
> 
> On Fri, Mar 11, 2016 at 7:40 AM, Jon Lewis  wrote:
>> On Thu, 10 Mar 2016, William Herrin wrote:
>>> It's Cogent's fault because: double-billing. Google should not have to
>>> pay Cogent for a service which you have already paid Cogent to provide
>>> to you. Cogent's demand is unethical. They intentionally fail to
>>> deliver on the basic service expectation you pay them for and refuse
>>> to do so unless a third party to your contract also pays them.
>> 
>> That's one way of looking at it.
>> 
>> However, which of your transits don't bill for bits exchanged with other
>> customers of theirs...and how are they or you accounting for that traffic?
> 
> Hi Jon,
> 
> As you know, there is a technology limitation in how routing works
> which says that for any given block of addresses you can, absent
> extraordinary measures, have a peering relationship or a transit
> relationship but not both. If both parties choose to have a transit

Not really.

If you have both, then there’s no easy way to guarantee that you get
paid for every piece of transit (though relatively simple localpref
tactics will actually make it likely that you also get paid for
many bits of peering).

> relationship, that excludes a peering relationship for the relevant
> blocks of addresses. And that's OK when _both sides_ choose it.

Your premise is flawed.

> In related news, no ethical conundrum demands defiance of the law of gravity.

True, but gravity is real. Your law of peering vs. transit above is
purely artificial and fails utterly if you don’t accept that an approximation
of which bits fall into which category is “close enough” for billing
purposes.

I’m not making any value judgments on whether accepting that idea is good
or bad. I know that there are networks that act in various ways on both
sides of this idea.

However, equating it to “the law of gravity” is rather silly given that it
is 100% mutable if we take the accounting out of the picture.

No amount of monetary policy change can counteract gravity.

Owen

RE: Cogent - Google - HE Fun

[Damien Burke]

Just received an updated statement from cogent support:

"We appreciate your concerns. This is a known issue that originates with Google 
as it is up to their discretion as to how they announce routes to us v4 or v6. 

Once again, apologies for any inconvenience."

And:

"The SLA does not cover route transit beyond our network. We cannot route to 
IPs that are not announced to us by the IP owner, directly or through a network 
peer."

Re: Why the US Government has so many data centers

[Sean Donelan]

On Sat, 12 Mar 2016, Roland Dobbins wrote:
The U.S. Government has an odd defintion of what is a data center, which 
ends up with a lot of things no rational person would call a data center.


There's also a case to be made that governmental organizations really 
oughtn't to have servers just lying around in random rooms, and that those 
rooms are de facto government data centers, whether those who're responsible 
for said rooms/servers know it or not . . .


If that is the goal, don't call it data center optimization.  That is 
server optimization.


When you say "data center" to an ordinary, average person or reporter; 
they think of big buildings filled with racks of computers.  Not a lonely 
server sitting in a test lab or under someone's desk.

Re: Why the US Government has so many data centers

[Sean Donelan]

On Fri, 11 Mar 2016, Christopher Morrow wrote:

 o 'a machine under your desk' is not a production operation.
(if you think it is, please stop, think again and move that
service to conditioned power/cooling/ethernet)


Even worse, the new OMB data center definition wants says "(whether in a 
production, test, stage, development, or any other environment)".


In the non-government world, you want to keep test, staging and 
development separate from your "production."  So your testing lab

is now a "data center," and you must consolidate your "data centers"
together.

If you are optimizing servers, not data centers, then you probably
want to consolidate your production servers in a data center.  But
there will still be lots of servers not in data centers, like the
server in the parking garage that controls the gates or the server
in the building that controls HVAC.  Its not smart to consolidate your
HVAC servers and your credit card servers, as some companies have
found out.

The U.S. government definition of data center is a bit like defining
a warehouse as any room containing a single ream of paper.  Yes, 
warehouses are used to store reams of paper; but that doesn't make

every place containing a ream of paper a warehouse.

RE: Why the US Government has so many data centers

[Steve Mikulasik]

This is a great way to create a mess of rules. Need a server for running an app 
locally to a site? You need XYZ standards that make no sense for your deploy 
and increase the cost by 10 times. 

Our server guys always try to set standards, then they run into a deploy where 
the needs are simple, but the standards make it significantly uneconomical.


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Sean Donelan
Sent: Friday, March 11, 2016 1:55 PM
To: Christopher Morrow 
Cc: nanog list 
Subject: Re: Why the US Government has so many data centers

On Fri, 11 Mar 2016, Christopher Morrow wrote:
>  o 'a machine under your desk' is not a production operation.
> (if you think it is, please stop, think again and move that 
> service to conditioned power/cooling/ethernet)

Even worse, the new OMB data center definition wants says "(whether in a 
production, test, stage, development, or any other environment)".

In the non-government world, you want to keep test, staging and development 
separate from your "production."  So your testing lab is now a "data center," 
and you must consolidate your "data centers"
together.

If you are optimizing servers, not data centers, then you probably want to 
consolidate your production servers in a data center.  But there will still be 
lots of servers not in data centers, like the server in the parking garage that 
controls the gates or the server in the building that controls HVAC.  Its not 
smart to consolidate your HVAC servers and your credit card servers, as some 
companies have found out.

The U.S. government definition of data center is a bit like defining a 
warehouse as any room containing a single ream of paper.  Yes, warehouses are 
used to store reams of paper; but that doesn't make every place containing a 
ream of paper a warehouse.

RE: Why the US Government has so many data centers

[Scott Weeks]

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Sean Donelan

The U.S. government definition of data center is a bit like defining 
a warehouse as any room containing a single ream of paper.  Yes, 
warehouses are used to store reams of paper; but that doesn't make 
every place containing a ream of paper a warehouse.


--- steve.mikula...@civeo.com wrote:

This is a great way to create a mess of rules. Need a server 
for running an app locally to a site? You need XYZ standards 
that make no sense for your deploy and increase the cost by 
10 times. 

Our server guys always try to set standards, then they run 
into a deploy where the needs are simple, but the standards 
make it significantly uneconomical.
-


Been there, done that, got many t-shirts.  There is no thought
at all to economics.  None.  People that have absolutely no 
experience in networking or computers (read: can barely operate 
M$ computers) make these rules/definitions/processes.  It's not 
even sausage when they're done.  It's post-digested sausage.  
For example, read about the OPM fiasco: 

https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach

I'm one of those 21.5 million people.  Fingerprints, SSN, 
address, etc, etc, etc.


scott

Re: Why the US Government has so many data centers

[Peter Kristolaitis]

On 2016-03-11 04:40 PM, Scott Weeks wrote:

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Sean Donelan

The U.S. government definition of data center is a bit like defining
a warehouse as any room containing a single ream of paper.  Yes,
warehouses are used to store reams of paper; but that doesn't make
every place containing a ream of paper a warehouse.


--- steve.mikula...@civeo.com wrote:

This is a great way to create a mess of rules. Need a server
for running an app locally to a site? You need XYZ standards
that make no sense for your deploy and increase the cost by
10 times.

Our server guys always try to set standards, then they run
into a deploy where the needs are simple, but the standards
make it significantly uneconomical.
-


Been there, done that, got many t-shirts.  There is no thought
at all to economics.  None.  People that have absolutely no
experience in networking or computers (read: can barely operate
M$ computers) make these rules/definitions/processes.  It's not
even sausage when they're done.  It's post-digested sausage.
For example, read about the OPM fiasco:

https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach

I'm one of those 21.5 million people.  Fingerprints, SSN,
address, etc, etc, etc.


scott


I disagree.  Government departments are heavily concerned about 
economics.  Specifically, "how can we maintain, or preferably increase, 
our budget in the next fiscal cycle?"   If that means feeding 500 lbs of 
pork to a chihuahua so you can burn up this year's budget, then so be 
it.  Next year you can ask for extra money to put the chihuahua on a 
special, extremely expensive diet while simultaneously asking for more 
pork to enrich its diet.

Re: Why the US Government has so many data centers

[Scott Weeks]

On 2016-03-11 04:40 PM, Scott Weeks wrote:
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Sean Donelan
>
> The U.S. government definition of data center is a bit like defining
> a warehouse as any room containing a single ream of paper.  Yes,
> warehouses are used to store reams of paper; but that doesn't make
> every place containing a ream of paper a warehouse.
> 
>
> --- steve.mikula...@civeo.com wrote:
>
> This is a great way to create a mess of rules. Need a server
> for running an app locally to a site? You need XYZ standards
> that make no sense for your deploy and increase the cost by
> 10 times.
>
> Our server guys always try to set standards, then they run
> into a deploy where the needs are simple, but the standards
> make it significantly uneconomical.
> -
>
>
> Been there, done that, got many t-shirts.  There is no thought
> at all to economics.  None.  People that have absolutely no
> experience in networking or computers (read: can barely operate
> M$ computers) make these rules/definitions/processes.  It's not
> even sausage when they're done.  It's post-digested sausage.
> For example, read about the OPM fiasco:
>
> https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach
>
> I'm one of those 21.5 million people.  Fingerprints, SSN,
> address, etc, etc, etc.



--- alte...@alter3d.ca wrote:--
From: Peter Kristolaitis 

I disagree.  Government departments are heavily concerned about 
economics.  Specifically, "how can we maintain, or preferably increase, 
our budget in the next fiscal cycle?"   If that means feeding 500 lbs of 
pork to a chihuahua so you can burn up this year's budget, then so be 
it.  Next year you can ask for extra money to put the chihuahua on a 
special, extremely expensive diet while simultaneously asking for more 
pork to enrich its diet.
--


Ok, put that way you're correct.  It's really disgusting to watch the
waste knowing how hard I work for my money and how badly it's pissed
into the wind.

scott

Re: AW: Cogent - Google - HE Fun

[Randy Bush]

> Anyone who is multihomed with cogent ipv6 in their mix should shutdown
> their IPv6 bgp session. Let’s see if we can make their graph freefall.

Ettore Bugatti, maker of the finest cars of his day, was once asked why his
cars had less than perfect brakes.  He replied something like, "Any fool can
make a car stop.  It takes a genius to make a car go."