Re: Cleveland/Cincinnati Co-location

[David Kehoe]

Not sure. From what I understood it sounds like Level 3's old network. But not 
100% sure.

Thank you,

David Kehoe | Information Security Analyst

d 330.757.0724 x5208 | c 567.233.2624 | www.pdmi.com

PDMI | 1170 E. Western Reserve Road | Poland, Ohio 44514

Sent from Mobile

Confidentiality Notice: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it, may contain confidential information. 
If you are not the intended recipient, or a person responsible for delivering 
it to the intended recipient, you are hereby notified that any disclosure, 
copying, distribution or use of any of the information contained in or attached 
to this message is STRICTLY PROHIBITED. If you have received this transmission 
in error, please immediately notify the sender by reply e-mail or by telephone 
at (330) 757-0724, and destroy the original transmission and its attachments 
without reading them or saving them to disk.

HIPAA NOTICE: It is against PDMI's policy to receive or send un-encrypted or 
non-secured E-mail correspondence containing Protected Health Information (PHI) 
as defined by the Health Insurance Portability and Accountability Act of 1996, 
as amended. Any email containing PHI is encrypted and sent securely.




On Sun, Jan 6, 2019 at 7:06 PM -0500, "Crist Clark" 
mailto:cjc+na...@pumpky.net>> wrote:



On Sun, Jan 6, 2019 at 2:52 PM Ross Tajvar 
mailto:r...@tajvar.io>> wrote:
I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has an 
AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, is on 
the Century Link backbone, and has a solid rubber roof with no holes or cooling 
systems on the roof.)

Being on the CenturyLink backbone doesn't sound like a selling point to me...

Also, which “CenturyLink?” Given it’s a DC, old Savvis network? Or Qwest? Or 
Level3? Or another acquisition?

Re: Cleveland/Cincinnati Co-location

[Crist Clark]

On Sun, Jan 6, 2019 at 2:52 PM Ross Tajvar  wrote:

> I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has
>> an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH,
>> is on the Century Link backbone, and has a solid rubber roof with no holes
>> or cooling systems on the roof.)
>
>
> Being on the CenturyLink backbone doesn't sound like a selling point to
> me...
>

Also, which “CenturyLink?” Given it’s a DC, old Savvis network? Or Qwest?
Or Level3? Or another acquisition?

>

Re: Cleveland/Cincinnati Co-location

[Ross Tajvar]

>
> I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has
> an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH,
> is on the Century Link backbone, and has a solid rubber roof with no holes
> or cooling systems on the roof.)


Being on the CenturyLink backbone doesn't sound like a selling point to
me...

On Fri, Jan 4, 2019 at 8:46 PM David Kehoe  wrote:

> Former employer was in Expedient’s DC. You can honestly do better than
> Expedient. Look into the Power Redundancy, Cooling Efficiency of the
> building, if the site is a purpose built DC (Expedient in Cleveland is
> not). Is Cloud Connect for backups important? Have you identified your
> requirements? If you need a starting point look at the following: Data
> Center Certification (from the Uptime Institute), Distance, Compliance (if
> needed), Level of Controlled Access, Power SLA, N+1 Cooling, Multi-Homed
> ISPs, Uptime %, Monitoring, NOC, Purpose Built DC.
>
>
>
> Involta has a really good data center in Independence, Akron, and a very
> impressive site near Pittsburgh. They would give you the option of having
> Hot/Hot datacenters with their connectivity. I’m not sure if you have to be
> in Cleveland or Cincinnati, but Cyxtera has an AMAZING data center in
> Columbus. (The DC can withstand winds up 140 MPH, is on the Century Link
> backbone, and has a solid rubber roof with no holes or cooling systems on
> the roof.)
>
>
>
> Thank you,
>
>
>
> *David Kehoe*
>
>
>
> *From:* NANOG  *On Behalf Of *
> nanog-requ...@nanog.org
> *Sent:* Friday, January 4, 2019 7:00 AM
> *To:* nanog@nanog.org
> *Subject:* NANOG Digest, Vol 132, Issue 4
>
>
>
> Send NANOG mailing list submissions to
> nanog@nanog.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
> nanog-requ...@nanog.org
>
> You can reach the person managing the list at
> nanog-ow...@nanog.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
>
>
> Today's Topics:
>
> 1. Re: Cleveland/Cincinnati Co-location
> (Allen McKinley Kitchen (gmail))
> 2. Re: Service Provider NetFlow Collectors (Aaron)
> 3. Re: Cleveland/Cincinnati Co-location (Shawn Ritchie)
> 4. Re: Announcing Peering-LAN prefixes to customers (Andy Davidson)
> 5. Report on Legal Barriers to RPKI Adoption (Christopher S. Yoo)
> 6. 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461,
> 6762, 6830, 8220, 9002, 12956 (Dominik Bay)
> 7. Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511,
> 6461, 6762, 6830, 8220, 9002, 12956 (Jeff Shultz)
> 8. Astronaut accidently calls 911 from space (Sean Donelan)
> 9. Re: Cellular backup connections (Dovid Bender)
> 10. Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511,
> 6461, 6762, 6830, 8220, 9002, 12956 (Job Snijders)
>
>
> --
>
> Message: 1
> Date: Thu, 3 Jan 2019 10:50:45 -0500
> From: "Allen McKinley Kitchen (gmail)"
> 
> To: "Justin M. Streiner" 
> Cc: NANOG 
> Subject: Re: Cleveland/Cincinnati Co-location
> Message-ID: <91679af9-e310-463c-b427-630f69c02...@gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> +1 for Expedient. Not a current customer but a VERY satisfied former
> customer. (Decision to leave them was a foul case of penny-pincher
> mismanagement, above my pay grade and over my objections.)
>
> ..Allen
>
> > On Jan 3, 2019, at 01:00, Justin M. Streiner 
> wrote:
> >
> >> On Tue, 1 Jan 2019, Mitchell Lewis wrote:
> >>
> >> I am working on project that may involve building points of presence in
> Cleveland & Cincinnati. Any suggestions as to which colocation facility in
> each city to build in? The prime factor of consideration for this project
> is access to waves to places like Chicago, New York & Ashburn. It would be
> nice to have multiple wave provider options to choose from.
> >>
> >> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in
> Cleveland.
> >
> > Expedient has two facilities in Cleveland that might be worth looking at.
> >
> > Thank you
> > jms
>
> --
>
> Message: 3
> Date: Thu, 3 Jan 2019 11:21:32 -0600
> From: Shawn Ritchie 
> To: "Allen McKinley Kitchen (gmail)" 
> Cc: "Justin M. Streiner" , NANOG
> 
> Subject: Re: Cleveland/Cincinnati Co-location
> Message-ID: <19433ff4-0e0c-4d7a-9cf2-cf385ae0a...@fastmail.fm>
> Content-Type: text/plain; charset=utf-8
>
> On Jan 3, 2019, at 9:50 AM, Allen McKinley Kitchen (gmail) <
> allenmckinleykitc...@gmail.com> wrote:
> >
> > +1 for Expedient. Not a current customer but a VERY satisfied former
> customer. (Decision to leave them was a foul case of penny-pincher
> mismanagement, above my pay grade and over my objections.)
> >
> > ..Allen
> >
> >> On Jan 3, 2019, at 01:00, Justin M. Streiner 
> wrote:
> >>
> >>> On Tue, 1 Jan 2019, Mitchell Lewis wrote:
> >>>
> >

Re: Report on Legal Barriers to RPKI Adoption

[Job Snijders]

Dear Christopher, David, NANOG community,

Thank you for your research and report. I found the report quite readable
(not having a legal background) and well structured. Definitely edifying
and worth the read! In this mail I’ll reply specifically to a few points
from the executive summary (and snip the rest).

For those of you who don’t want to create a SSRN account here is a copy of
the report:
http://instituut.net/~job/SSRN-id3309813.pdf


On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo  wrote:

> Here is a summary of our recommendations:
>
On the ROV side of the equation, the principal legal hindrances have to do
> with the terms and conditions governing access to the RPKI repository
> offered by ARIN in its Relying Party Agreement (“RPA”), and in the manner
> it has employed to ensure the agreement is binding. Regarding ROV:
>
> 1.   The goal of widespread ROV counsels in favor of ARIN reviewing
> its current approach to repository distribution, embodied in the RPA. We
> conclude that two paths would be reasonable. First, ARIN should consider
> dropping the RPA altogether. This would remove the most significant legal
> barriers to widespread utilization of the ARIN RPKI repository.
>


I’m happy to see suggestions that dropping the RPA is a viable path.

In December 2018 we’ve measured that around TWENTY percent of the networks
deploying RPKI based Origin Validation are missing the ARIN TAL [source:
benjojo]. This is an extremely worrying number, as it means that ARIN ROAs
are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the
root cause for ARIN being an outliner is absence of the ARIN TAL in the
common RPKI Validation softwares. The absence of the ARIN TAL in software
distributions can be directly attributed to the existence of the RPA and
applicable contract doctrines.

If no changes are made to the current situation, I expect the 20% number to
remain the same or even grow, effectively making ARIN’s RPKI services
unsuitable for the purpose of securing routing.


2.   Developers of RPKI validation software should consider integrating
> acceptance of ARIN’s RPA into their software workflows. ARIN recently
> enabled this possibility, and developers should deliberate on whether to
> capitalize on the opportunity.
>


To put it bluntly: item 2 is not going to happen.

We’ve discussed this extensively in the OpenBSD community (who are working
on a new RPKI Validation implementation [source: rpki-client]), and
concluded that collecting explicit consent to the RPA on behalf of ARIN is
undesirable and without precedent. This doesn’t exist for DNSSEC, TLS
certificates, or IRR data - and we’re not going to make an exception for
ARIN and encumber each and every OpenBSD or rpki-client(1) installation.

I checked the temperature in the room of the other relevant RPKI Validation
implementations, and it appears that *nobody* is planning to integrate
acceptance of ARIN’s RPA into their installation process.


4.   In addition to the important step ARIN has already taken to enable
> third-party software developers to integrate RPA acceptance into their
> software workflows, ARIN should consider reducing the barriers to
> third-party service development imposed by the RPA’s prohibited conduct
> clause. Specifically, ARIN should consider methods for allowing approved
> developers to make use of RPKI information as an input into more
> sophisticated services.
>
5.   Separately, ARIN should consider revising the prohibited conduct
> clause to allow broader distribution of information created with RPKI as an
> input for research and analysis purposes.
>


To provide context for the above two paragraphs, at this point in time it’s
unclear whether BGPMon’s WHOIS, NLNOG’s IRRExplorer, and the various “RPKI
to IRR” services are violating the RPA. I believe it to be highly
undesirable for this uncertainty to persist, nor would it be acceptable to
require each and every (potential) innovator or researcher to sign
contracts with ARIN. ARIN members would be significantly worse off if these
services stop using the ARIN TAL.

Finally, ARIN members should realize that the majority of ASNs on the
Internet are *outside* North America and are not ARIN members. We want
*all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and
misconfigurations don’t know borders. It’s not reasonable to require Dutch,
Indian, Russian and Chinese networks to enter into a contractual agreement
with ARIN in order to protect the ARIN members. This is why we need things
to work properly out of the box, just like was done with DNSSEC. Reform is
needed.

Kind regards,

Job

[benjojo]: https://blog.benjojo.co.uk/post/state-of-rpki-in-2018
[rpki-client]:
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65

Re: IP Dslams

[Sander Steffann]

Hi,

>> How many devices are you looking for?
>> Consider ZyXEL 1248: 
>> https://www.zyxel.com/uk/en/products_services/48-port-Temperature-Hardened-ADSL2--Box-DSLAM-IES-1248-5x-IES-1248-5xA-Series/
> 
> I had bad experiences with those.

My apologies, my problems were with a different Zyxel model (which I don't 
recall anymore).

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: Google Fiber v6 PD only giving /64

[Sander Steffann]

Hi,

> Anybody here from Google Fiber?  When I first got it last year, my IPv6
> setup got a /56 prefix delegated.  I now see that no matter what size I
> request, I only get a /64.  Is this intentional?

Sounds broken, especially considering how people like Lorenzo have always 
fought for giving everybody plenty of address space...

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP