Re: Cogent - Google - HE Fun

[Mark Tinka]

On 10/Mar/16 17:51, Owen DeLong wrote:

> I think it’s a little different from what you say…
>
> I think Google already reaches Cogent for IPv4 via transit.
>
> Google, long ago, announced that they would not be purchasing IPv6 transit 
> and that they have an open peering policy for anyone who wishes to reach 
> them. In order to avoid significant disruption, they haven’t terminated their 
> IPv4 transit contracts, but it certainly makes sense that they would not be 
> pursuing IPv6 transit contracts.

Understandable, but sort of moot if interconnect ports are dual-stack
and there are no discrete charges for IPv4 or IPv6.

Of course, if removal of IPv6 traffic saves bandwidth and operational
costs for Google interconnect with Cogent, then that makes sense to do.

Mark.

Re: AW: Cogent - Google - HE Fun

[Mark Tinka]

On 10/Mar/16 17:25, Jon Lewis wrote:

> My guess is that GOOG is playing peering chicken with Cogent on "the
> IPv6 Internet" because doing so is low impact.  Doing this with v4
> routing would be far more painful to both GOOG and single-homed Cogent
> customers (probably make the news and make one or both look bad). 
> Doing this with v6 keeps it off in the shadows...both parties know its
> an issue, but its likely not seriously impacting anyone yet.  GOOG
> likely thinks they're big enough and their content desirable enough,
> that Cogent should peer with them.  Cogent clearly disagrees.  I'm
> sure GOOG would prefer SFI with Cogent for v4 and v6...but they're
> working on getting v6 first.

Assuming the IPv6 traffic is traversing the same physical ports as IPv4
between both networks, it is actually unnecessary pain to not pass IPv6
traffic across their interconnect relationship, unless removal of IPv6
peering lowers traffic utilization significantly to negate the need for
Google to pay a higher rate to Cogent, and/or delay physical port speed
upgrades.

Mark.

RE: Figuring out traceroute

[Jürgen Jaritsch]

Looks like the device is always las-b3 (Los Angeles, border 3). As far as I 
know Telia works with IS-IS and multiple load balanced links from each bb 
(backbone) router to each border router. Usually they don't deal with L2 in 
case of customer BGP downlinks.



Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601


-Original Message-
From: Reza Motamedi [motam...@cs.uoregon.edu]
Received: Freitag, 11 März 2016, 1:26
To: nanog@nanog.org [nanog@nanog.org]
Subject: Figuring out traceroute

Hi guys,

This might seem a bit of a trivial question, but I guess there is no harm
in asking. I am looking at a collection of traceroutes all go through the
following consecutive hops (* >> 213.248.98.238), as shown here (I kept the
DNSname just for completeness):

+ From >> To
+ (213.155.130.125:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.130.127:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.75:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.83:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.85:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.251:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.77:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.57:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.59:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.114.111:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.168:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.170:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.174:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.176:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.178:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.180:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.182:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.184:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.186:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.188:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.190:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.255:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)

Given the way traceroute works (most of the times), which reports back the
ingress port of the router it hits, do you think it fair to assume that all
the hops that I see on the `From` hop are all different ports of one
router? I think the other explanation is that there is switch (or something
that does not have IP footprint) between `From` side and `To` side. How
probable do you think this second explanation is?

Best Regards
Reza Motamedi (R.M)

Re: Facebook & Traceroute

[Yang Yu]

On Thu, Mar 10, 2016 at 9:35 AM, Christopher Morrow
 wrote:

> unclear, that traceroute was from someplace I don't own the network for...
> from another place I do though...
>
>  5  ae0.dr07.ash2.tfbnw.net (31.13.26.233)  4 ms
> ae0.dr05.ash3.tfbnw.net (31.13.29.21)  4 ms ae0.dr08.ash2.tfbnw.net
> (31.13.26.235)  2 ms
>  6  * * *
>  7  * * *
>  8  * * *
>  9  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  3 ms  3 ms  2 ms
>
> same-ish results, no spoofed bits.

https://atlas.ripe.net/measurements/3612424/#!probes

I did a atlas measurement of 500 probes, 104 probes (21%) had their
outside IP shown in traceroute. Some peers of AS32934 don't have
ingress filtering. It seems all prefixes advertised by Facebook are
ROA signed and valid tho.

Figuring out traceroute

[Reza Motamedi]

Hi guys,

This might seem a bit of a trivial question, but I guess there is no harm
in asking. I am looking at a collection of traceroutes all go through the
following consecutive hops (* >> 213.248.98.238), as shown here (I kept the
DNSname just for completeness):

+ From >> To
+ (213.155.130.125:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.130.127:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.75:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.83:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.85:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.251:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.77:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.57:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.59:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.114.111:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.168:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.170:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.174:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.176:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.178:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.180:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.182:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.184:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.186:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.188:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.190:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.255:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)

Given the way traceroute works (most of the times), which reports back the
ingress port of the router it hits, do you think it fair to assume that all
the hops that I see on the `From` hop are all different ports of one
router? I think the other explanation is that there is switch (or something
that does not have IP footprint) between `From` side and `To` side. How
probable do you think this second explanation is?

Best Regards
Reza Motamedi (R.M)

Re: AW: Cogent - Google - HE Fun

[William Herrin]

On Thu, Mar 10, 2016 at 1:37 PM, Mike Hammett  wrote:

> Anyone that complains about double billing doesn't apparently know how the
> Internet works and should relegate themselves to writing articles for
> GigaOm.
>

Mike,

I picture you saying that with a Godfather voice and going on to talk about
friendship and respect.

Some very popular practices on the Internet are also very corrupt. That
they have 'always' been that way makes them no less corrupt.

-Bill




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

Re: Cogent - Google - HE Fun

[Matthew D. Hardeman]

Freddy,

As there is no IPv6 transit between HE and Cogent, this would have the effect 
of isolating ones network services from the single-homed customers of Cogent.  
I’m not sure that many of us could get away with that.  Further, I’m not sure 
that it’s appropriate to punish the single-homed Cogent customers.  I’ll grant, 
this is just what Google has done, but they’re well positioned to weather that 
storm and have a level of visibility and brand loyalty that will allow them to 
have a chance of success at it.

I think the softer approach of reducing the relevancy of Cogent’s IPv6 transit 
service and indeed the relevancy of peering with Cogent for IPv6 is a way 
forward that more of us could get behind.

Thanks,

Matt Hardeman

> On Mar 10, 2016, at 4:42 PM, Fredy Kuenzler  wrote:
> 
> This would work for those which are using IPv6 transit from Cogent.
> 
> For anyone else which is using IPv6 transit from Hurricane Electric and some 
> other suppliers such as L3 or NTT: to set the community 'do not announce to 
> Cogent' only on every other transit but HE would help to isolate Cogent 
> without much collateral damage. It would support Google/HE's position. And 
> maybe help to bring back Cogent onto a cooperative track, after all.
> 
> --
> Fredy Kuenzler
> Init7 (Switzerland) Ltd.
> St.-Georgen-Strasse 70
> CH-8400 Winterthur
> Switzerland
> 
> http://www.init7.net/
> 
> 
>> Am 10.03.2016 um 23:19 schrieb Matthew D. Hardeman :
>> 
>> I have contemplated whether such mechanisms matter to Cogent, etc.
>> 
>> I’m inclined to think that if Google is willing to pull the routes and they 
>> still don’t blink, then certainly us smaller shops aren’t going to impact 
>> them…
>> 
>> However…  If enough prefixes disappear from the _apparent_ Cogent table as 
>> viewed by outsiders, this may ultimately impact their sales of new 
>> interconnection….
>> 
>> For those of us multihomed with Cogent and other transit providers on IPv6 
>> there is a less drastic way to impact the perceived value of Cogent’s IPv6 
>> routing table to outsiders and especially to Cogent’s peers — and one that 
>> still doesn’t negatively impact the single-home customers of Cogent:
>> 
>> "set community 174:3000" on your IPv6 advertisement to Cogent.  This will 
>> constrain the advertisement to Cogent and Cogent’s customers only.  For good 
>> measure, prepend your own AS to this advertisement at least a couple of 
>> times, potentially discouraging even Cogent customers who see the route from 
>> using it if they have other transit.  It will prevent the path via Cogent 
>> being selected by Cogent IPv6 peers versus your other transit providers.
>> 
>> 
>>> On Mar 10, 2016, at 3:47 PM, Fredy Kuenzler  wrote:
>>> 
>>> Am 10.03.2016 um 22:25 schrieb Damien Burke :
 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.
>>> 
>>> 
>>> Alternative:
>>> 
>>> set community [do not announce to Cogent]
>>> 
>>> *SCNR*
>> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Cogent - Google - HE Fun

[Matthew D. Hardeman]

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



smime.p7s
Description: S/MIME cryptographic signature

Re: Cogent - Google - HE Fun

[Fredy Kuenzler]

This would work for those which are using IPv6 transit from Cogent.

For anyone else which is using IPv6 transit from Hurricane Electric and some 
other suppliers such as L3 or NTT: to set the community 'do not announce to 
Cogent' only on every other transit but HE would help to isolate Cogent without 
much collateral damage. It would support Google/HE's position. And maybe help 
to bring back Cogent onto a cooperative track, after all.

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
St.-Georgen-Strasse 70
CH-8400 Winterthur
Switzerland

http://www.init7.net/


> Am 10.03.2016 um 23:19 schrieb Matthew D. Hardeman :
> 
> I have contemplated whether such mechanisms matter to Cogent, etc.
> 
> I’m inclined to think that if Google is willing to pull the routes and they 
> still don’t blink, then certainly us smaller shops aren’t going to impact 
> them…
> 
> However…  If enough prefixes disappear from the _apparent_ Cogent table as 
> viewed by outsiders, this may ultimately impact their sales of new 
> interconnection….
> 
> For those of us multihomed with Cogent and other transit providers on IPv6 
> there is a less drastic way to impact the perceived value of Cogent’s IPv6 
> routing table to outsiders and especially to Cogent’s peers — and one that 
> still doesn’t negatively impact the single-home customers of Cogent:
> 
> "set community 174:3000" on your IPv6 advertisement to Cogent.  This will 
> constrain the advertisement to Cogent and Cogent’s customers only.  For good 
> measure, prepend your own AS to this advertisement at least a couple of 
> times, potentially discouraging even Cogent customers who see the route from 
> using it if they have other transit.  It will prevent the path via Cogent 
> being selected by Cogent IPv6 peers versus your other transit providers.
> 
> 
>> On Mar 10, 2016, at 3:47 PM, Fredy Kuenzler  wrote:
>> 
>> Am 10.03.2016 um 22:25 schrieb Damien Burke :
>>> 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.
>> 
>> 
>> Alternative:
>> 
>> set community [do not announce to Cogent]
>> 
>> *SCNR*
> 

Re: Cogent - Google - HE Fun

[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.

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

[Matthew D. Hardeman]

I have contemplated whether such mechanisms matter to Cogent, etc.

I’m inclined to think that if Google is willing to pull the routes and they 
still don’t blink, then certainly us smaller shops aren’t going to impact them…

However…  If enough prefixes disappear from the _apparent_ Cogent table as 
viewed by outsiders, this may ultimately impact their sales of new 
interconnection….

For those of us multihomed with Cogent and other transit providers on IPv6 
there is a less drastic way to impact the perceived value of Cogent’s IPv6 
routing table to outsiders and especially to Cogent’s peers — and one that 
still doesn’t negatively impact the single-home customers of Cogent:

"set community 174:3000" on your IPv6 advertisement to Cogent.  This will 
constrain the advertisement to Cogent and Cogent’s customers only.  For good 
measure, prepend your own AS to this advertisement at least a couple of times, 
potentially discouraging even Cogent customers who see the route from using it 
if they have other transit.  It will prevent the path via Cogent being selected 
by Cogent IPv6 peers versus your other transit providers.


> On Mar 10, 2016, at 3:47 PM, Fredy Kuenzler  wrote:
> 
> Am 10.03.2016 um 22:25 schrieb Damien Burke :
>> 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.
> 
> 
> Alternative:
> 
> set community [do not announce to Cogent]
> 
> *SCNR*



smime.p7s
Description: S/MIME cryptographic signature

Re: AW: Cogent - Google - HE Fun

[Fredy Kuenzler]

Am 10.03.2016 um 22:25 schrieb Damien Burke :
> 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.


Alternative:

set community [do not announce to Cogent]

*SCNR*

RE: AW: Cogent - Google - HE Fun

[Damien Burke]

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.



[cid:image001.png@01D17AD0.248335A0]



http://bgp.he.net/AS174#_asinfo





-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William Herrin
Sent: Thursday, March 10, 2016 7:56 AM
To: Dennis Burgess
Cc: North American Network Operators' Group
Subject: Re: AW: Cogent - Google - HE Fun



On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess 
> wrote:

> Not wishing to get into a pissing war with who is right or wrong, but

> it sounds like google already pays or has an agreement with cogent for

> v4, as that's unaffected, cogent says google is simply not advertising

> v6 prefixes to them, so, how is that cogent's fault?



Hi Dennis,



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.



If you're not single-homed to Cogent and you have the balls for it, I would 
file an outage with Cogent and demand service credit until they resolve their 
IPv6 access problem with Google. And then refuse to pay until they connect with 
Google.



If you are single-homed to Cogent, it's *very* important that you do something 
about that before you get burned in a way that matters.



Regards,

Bill Herrin







--

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

Re: AW: Cogent - Google - HE Fun

[Mike Hammett]

Anyone that complains about double billing doesn't apparently know how the 
Internet works and should relegate themselves to writing articles for GigaOm. 
Oh 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "William Herrin"  
To: "Dennis Burgess"  
Cc: "North American Network Operators' Group"  
Sent: Thursday, March 10, 2016 9:55:30 AM 
Subject: Re: AW: Cogent - Google - HE Fun 

On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess 
 wrote: 
> Not wishing to get into a pissing war with who is right or wrong, but it 
> sounds like 
> google already pays or has an agreement with cogent for v4, as that's 
> unaffected, 
> cogent says google is simply not advertising v6 prefixes to them, so, how is 
> that cogent's fault? 

Hi Dennis, 

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. 

If you're not single-homed to Cogent and you have the balls for it, I 
would file an outage with Cogent and demand service credit until they 
resolve their IPv6 access problem with Google. And then refuse to pay 
until they connect with Google. 

If you are single-homed to Cogent, it's *very* important that you do 
something about that before you get burned in a way that matters. 

Regards, 
Bill Herrin 



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

Re: Cogent - Google - HE Fun

[Stephen Frost]

* William Herrin (b...@herrin.us) wrote:
> Guys, that would be an important distinction if Cogent were providing
> Dennis with free service. They're not. Regardless of what Google does
> or doesn't do, Dennis pays Cogent to connect him to the wide Internet
> which emphatically includes Google. I'm sorry I said anything at all
> about Dennis' relationship with Google because that is immaterial to
> whether Cogent is honorably fulfilling its contract with Dennis.

Please tell me when I can get Verizon FiOS to agree that they're
supposed to provide me with access to the wide Internet, which includes
everything IPv6.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: Cogent - Google - HE Fun

[Owen DeLong]

> On Mar 10, 2016, at 09:29 , William Herrin  wrote:
> 
> On Thu, Mar 10, 2016 at 11:56 AM, Owen DeLong  wrote:
>>> On Mar 10, 2016, at 08:24 , Chris Adams  wrote:
>>> Once upon a time, Owen DeLong  said:
 In fairness, however, this is because he is not Google’s customer, he
 is Google’s product.
>>> 
>>> False supposition; Google does actually sell services as well.  $DAYJOB
>>> pays Google for services, and has paid Cogent for network access.
>> 
>> Not my assumption… Assumption included from Bill Herrin’s message…
>> 
>>> Google, by contrast, makes no demand that Cogent pay them even though
>>> you are not paying Google for service.
> 
> 
> Guys, that would be an important distinction if Cogent were providing
> Dennis with free service. They're not. Regardless of what Google does
> or doesn't do, Dennis pays Cogent to connect him to the wide Internet
> which emphatically includes Google. I'm sorry I said anything at all
> about Dennis' relationship with Google because that is immaterial to
> whether Cogent is honorably fulfilling its contract with Dennis.

Which doesn’t disagree with anything I said.

Owen

Re: Cogent - Google - HE Fun

[William Herrin]

On Thu, Mar 10, 2016 at 11:56 AM, Owen DeLong  wrote:
>> On Mar 10, 2016, at 08:24 , Chris Adams  wrote:
>> Once upon a time, Owen DeLong  said:
>>> In fairness, however, this is because he is not Google’s customer, he
>>> is Google’s product.
>>
>> False supposition; Google does actually sell services as well.  $DAYJOB
>> pays Google for services, and has paid Cogent for network access.
>
> Not my assumption… Assumption included from Bill Herrin’s message…
>
>> Google, by contrast, makes no demand that Cogent pay them even though
>> you are not paying Google for service.


Guys, that would be an important distinction if Cogent were providing
Dennis with free service. They're not. Regardless of what Google does
or doesn't do, Dennis pays Cogent to connect him to the wide Internet
which emphatically includes Google. I'm sorry I said anything at all
about Dennis' relationship with Google because that is immaterial to
whether Cogent is honorably fulfilling its contract with Dennis.

Regards,
Bill Herrin


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

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Thu, 10 Mar 2016, Tassos Chatzithomaoglou wrote:


Mikael Abrahamsson wrote on 10/3/16 18:21:


However, I stand by my earlier statement that we need to include MTU/MRU in ND 
messages, so that this can be negotiated on a LAN where not all devices support 
large MTU.



Isn't this already supported?
https://tools.ietf.org/html/rfc4861#section-4.6.4


That is in RAs, and pertains to a prefix. Also, if a device can't use the 
advertised MTU, they will keep lower MTU which might be causing MTU 
mismatch.


For instance, if I announce 9000 as MTU and a device is bridged via wifi, 
wifi chips generally only supports around 2300 in MTU, so you'll have MTU 
mismatch with MTU blackholing within the same L2 network. This is bad.


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

Re: Cogent - Google - HE Fun

[Owen DeLong]

> On Mar 10, 2016, at 08:24 , Chris Adams  wrote:
> 
> Once upon a time, Owen DeLong  said:
>> In fairness, however, this is because he is not Google’s customer, he
>> is Google’s product. Google is selling him (well, information about him
>> anyway) to their customers. They gather this information by offering
>> certain things he wants in exchange for him allowing them to collect
>> and redistribute this data.
> 
> False supposition; Google does actually sell services as well.  $DAYJOB
> pays Google for services, and has paid Cogent for network access.

Not my assumption… Assumption included from Bill Herrin’s message…

> Google, by contrast, makes no demand that Cogent pay them even though
> you are not paying Google for service. 

(Underline added for emphasis)

Owen

Re: Internet Exchanges supporting jumbo frames?

[Tassos Chatzithomaoglou]

Mikael Abrahamsson wrote on 10/3/16 18:21:
>
> However, I stand by my earlier statement that we need to include MTU/MRU in 
> ND messages, so that this can be negotiated on a LAN where not all devices 
> support large MTU.
>

Isn't this already supported?
https://tools.ietf.org/html/rfc4861#section-4.6.4

--
Tassos

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Mikael Abrahamsson wrote:
> However, I stand by my earlier statement that we need to include MTU/MRU
> in ND messages, so that this can be negotiated on a LAN where not all
> devices support large MTU.

this would introduce a degree of network complexity that is unnecessary
and would be prone to problems.  It might be nice to have an
auto-configurable maximum frame size per broadcast domain, though.

Nick

Re: Cogent - Google - HE Fun

[Chris Adams]

Once upon a time, Owen DeLong  said:
> In fairness, however, this is because he is not Google’s customer, he
> is Google’s product. Google is selling him (well, information about him
> anyway) to their customers. They gather this information by offering
> certain things he wants in exchange for him allowing them to collect
> and redistribute this data.

False supposition; Google does actually sell services as well.  $DAYJOB
pays Google for services, and has paid Cogent for network access.

-- 
Chris Adams 

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Thu, 10 Mar 2016, Saku Ytti wrote:


On 10 March 2016 at 02:44, Niels Bakker 

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Thu, 10 Mar 2016, Niels Bakker wrote:

You're wrong here.  The IXP switch platform cannot send ICMP Packet Too 
Big messages.  That's why everybody must agree on one MTU.


"Someone" should do an inventory of the market to find out how many 
commonly used platforms limit MRU to less than 9180 (L3), if MTU is set to 
1500.


Because if most platforms do not limit MRU, then the impact of MTU 
mismatch on the peering LAN is actually a lot less than otherwise.


However, I stand by my earlier statement that we need to include MTU/MRU 
in ND messages, so that this can be negotiated on a LAN where not all 
devices support large MTU.


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

Re: finding whois servers, was .pro whois registry down?

[Tony Finch]

John Levine  wrote:
>
> I've set up .ws.sp.am (that's ws for Whois Server) which is
> updated every day from a variety of sources so it's pretty accurate.
> It's had the right server for pro.ws.sp.am all along.

It would be extra super helpful if every entry were a wildcard, so you
could look up (say) example.com.ws.sp.am and get a CNAME for the right
whois server. The reason for this is that the relevant whois server is not
always keyed off just the TLD, and sometimes the TLD doesn't provide a
referral. A particular case I know of is ac.uk vs. uk. You could have

*.uk.ws.sp.am.CNAME whois.nic.uk.
*.ac.uk.ws.sp.am. CNAME whois.ja.net.

Then I could look up cambridge.ac.uk.ws.sp.am and
cambridge.net.uk.ws.sp.am and get the right pointer in each case with a
single DNS lookup.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Southeast Fitzroy: Northerly 5 or 6, becoming variable 4 in north and west.
Rough becoming moderate later. Mainly fair. Good.

Re: finding whois servers, was .pro whois registry down?

[Raymond Dijkxhoorn]

Hai!


whois.conf-compatible format



What uses whois.conf?   Not the whois on my FreeBSD or Mac.

Or you can just use this shell script:

#!/bin/bash
WHOISHOST=${1##*.}.ws.sp.am
exec whois -h $WHOISHOST $*


I just a slightly different one but still my fav one... jwhois

Has a whois.conf style list.

Bye,
Raymond.

Re: Cogent - Google - HE Fun

[Owen DeLong]

> On Mar 10, 2016, at 07:55 , William Herrin  wrote:
> 
> On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess
>  wrote:
>> Not wishing to get into a pissing war with who is right or wrong, but it 
>> sounds like
>> google already pays or has an agreement with cogent for v4, as that's 
>> unaffected,
>> cogent says google is simply not advertising v6 prefixes to them, so, how is
>> that cogent's fault?
> 
> Hi Dennis,
> 
> 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.

In fairness, however, this is because he is not Google’s customer, he
is Google’s product. Google is selling him (well, information about him
anyway) to their customers. They gather this information by offering
certain things he wants in exchange for him allowing them to collect
and redistribute this data.

Everything you say above is true, but let’s be clear where the customer
vs. product relationships truly are.

Owen

Re: finding whois servers, was .pro whois registry down?

[John R. Levine]

- a link from that top-level page to the whole list, in regex-aware,
whois.conf-compatible format


What uses whois.conf?   Not the whois on my FreeBSD or Mac.

Or you can just use this shell script:

 #!/bin/bash
 WHOISHOST=${1##*.}.ws.sp.am
 exec whois -h $WHOISHOST $*

R's,
John

Re: finding whois servers, was .pro whois registry down?

[Royce Williams]

On Thu, Mar 10, 2016 at 6:57 AM, John R. Levine  wrote:
>>>
>>> I've set up .ws.sp.am (that's ws for Whois Server) which is
>>> updated every day from a variety of sources so it's pretty accurate.
>>> It's had the right server for pro.ws.sp.am all along.
>
>
>> Hey, that's fantastic!
>>
>> Feature request: could you provide a human- and machine-readable one-stop
>> extract at the top-level page (ws.sp.am) ?
>
>
> I can make a web page, but not sure what you mean by one-stop extract.  If 
> you mean a proxy that will do the whois lookups, no, because it'd get abused 
> and I'd get rate limited.

Definitely not a proxy request - I know exactly what that would mean.

The goal would be to provide a unified list of the servers for each
TLD, to help people who cannot change their whois client for
administrative/political/inertia reasons, but have control over their
whois.conf, a la:

https://superuser.com/questions/758647/how-to-whois-new-tlds

So in an ideal world:

- a top-level landing page that would explain briefly what it's for, and

- a link from that top-level page to the whole list, in regex-aware,
whois.conf-compatible format

Royce

anyone from google email / net ops here?

[Josh Reynolds]

It seems like one of your email servers is on SORBS which is causing
any email outbound from said server to be blocked by those using
SORBS.

IP in question is 209.85.214.170

Offlist responses are fine, thanks

Re: finding whois servers, was .pro whois registry down?

[John R. Levine]

I've set up .ws.sp.am (that's ws for Whois Server) which is
updated every day from a variety of sources so it's pretty accurate.
It's had the right server for pro.ws.sp.am all along.



Hey, that's fantastic!

Feature request: could you provide a human- and machine-readable one-stop
extract at the top-level page (ws.sp.am) ?


I can make a web page, but not sure what you mean by one-stop extract.  If 
you mean a proxy that will do the whois lookups, no, because it'd get 
abused and I'd get rate limited.


R's,
John

Re: AW: Cogent - Google - HE Fun

[William Herrin]

On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess
 wrote:
> Not wishing to get into a pissing war with who is right or wrong, but it 
> sounds like
> google already pays or has an agreement with cogent for v4, as that's 
> unaffected,
> cogent says google is simply not advertising v6 prefixes to them, so, how is
> that cogent's fault?

Hi Dennis,

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.

If you're not single-homed to Cogent and you have the balls for it, I
would file an outage with Cogent and demand service credit until they
resolve their IPv6 access problem with Google. And then refuse to pay
until they connect with Google.

If you are single-homed to Cogent, it's *very* important that you do
something about that before you get burned in a way that matters.

Regards,
Bill Herrin



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

Re: Cogent - Google - HE Fun

[Owen DeLong]

I think it’s a little different from what you say…

I think Google already reaches Cogent for IPv4 via transit.

Google, long ago, announced that they would not be purchasing IPv6 transit and 
that they have an open peering policy for anyone who wishes to reach them. In 
order to avoid significant disruption, they haven’t terminated their IPv4 
transit contracts, but it certainly makes sense that they would not be pursuing 
IPv6 transit contracts.

The situation with Hurricane Electric is somewhat similar.

Google and HE are two of the most significant IPv6 networks out there. In the 
IPv6 world, Cogent is basically an also-ran so far.

The peering dynamics are different in IPv4 and IPv6 because the adoption rates 
and deployments in various networks have been different.

Cogent is sticking their head in the sand and pretending that their IPv4 
peering status should carry over into IPv6 automatically.

One of two things will eventually happen…

Either Cogent will win this game of chicken and the IPv6 networks that are not 
paying to reach them by transit now will start paying to do so, or, Cogent will 
lose this game of chicken and become progressively less relevant in the IPv6 
internet.

Personally, my bet is on the latter. For historical precedent, I refer you to 
SPRINT (AS1239).

Owen

> On Mar 10, 2016, at 07:09 , Dennis Burgess  wrote:
> 
> Not wishing to get into a pissing war with who is right or wrong, but it 
> sounds like google already pays or has an agreement with cogent for v4, as 
> that's unaffected, cogent says google is simply not advertising v6 prefixes 
> to them, so, how is that cogent's fault?
> 
> 
> -Original Message-
> From: Jon Lewis [mailto:jle...@lewis.org] 
> Sent: Wednesday, March 9, 2016 11:26 AM
> To: Jürgen Jaritsch 
> Cc: Dennis Burgess ; North American Network 
> Operators' Group 
> Subject: Re: AW: Cogent - Google - HE Fun
> 
> In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm 
> not surprised.  I suggested it during talks with GOOG roughly 10 years 
> ago...not saying I had any influence...I'm pretty sure I did not. :)
> 
> GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them 
> or someone else to get to Cogent).  If you're well peered / multihomed, it's 
> not much of an issue.  If you're a single-homed Cogent customer, you should 
> complain to Cogent that they're not providing full
> IPv6 connectivity.
> 
> On Wed, 9 Mar 2016, Jürgen Jaritsch wrote:
> 
>> Hi,
>> 
>> mail from Cogent:
>> 
>> Dear Cogent Customer,
>> 
>> Thank you for contacting Cogent Customer Support for information about the 
>> Google IPv6 addresses you are unable to reach.
>> 
>> Google uses transit providers to announce their IPv4 routes to Cogent.
>> 
>> At this time however, Google has chosen not to announce their IPv6 routes to 
>> Cogent through transit providers.
>> 
>> We apologize for any inconvenience this may cause you and will notify you if 
>> there is an update to the situation.
>> 
>> 
>> Mail from Google:
>> 
>> Unfortunately it seems that your transit provider does not have IPv6 
>> connectivity with Google. We suggest you ask your transit provider to look 
>> for alternatives to interconnect with us.
>> 
>> Google maintains an open interconnect policy for IPv6 and welcomes any 
>> network to peer with us for access via IPv6 (and IPv4). For those networks 
>> that aren't able, or chose not to peer with Google via IPv6, they are able 
>> to reach us through any of a large number of transit providers.
>> 
>> For more information in how to peer directly with Google please visit 
>> https://peering.google.com 
>> 
>> best regards
>> 
>> Jürgen Jaritsch
>> Head of Network & Infrastructure
>> 
>> ANEXIA Internetdienstleistungs GmbH
>> 
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>> 
>> E-Mail: jjarit...@anexia-it.com
>> Web: http://www.anexia-it.com
>> 
>> 
>> 
>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 
>> Klagenfurt
>> Geschäftsführer: Alexander Windbichler
>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT 
>> U63216601
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: NANOG [mailto:nanog-bounces+jjaritsch=anexia-it@nanog.org] Im 
>> Auftrag von Dennis Burgess
>> Gesendet: Mittwoch, 09. März 2016 17:01
>> An: North American Network Operators' Group
>> Betreff: Cogent - Google - HE Fun
>> 
>> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at 
>> all. I was told google pulled all of their peering with Cogent?   If I bring 
>> up a SIT tunnel with HE, I get the prefixes but at horrible speed and 
>> latency .. anyone else?
>> 
>> [DennisBurgessSignature]
>> www.linktechs.net - 314-735-0270 x103 - 
>> dmburg...@linktechs.net
>> 
>> 
> 
> 

Re: finding whois servers, was .pro whois registry down?

[Royce Williams]

On Thu, Mar 10, 2016 at 4:32 AM, John Levine  wrote:

> >   _whois._tcp.pro. srv 0 100 43 whois.afilias.net.
>
> A swell idea, but unfortunately the idea of putting SRV records in
> gTLD zones makes heads at ICANN explode.  For RDAP there's a registry
> at IANA but it's not populated yet and it's not obvious that registries
> will be any more diligent about updating it than they are for the WHOIS
> entries in the TLD database.
>
> >If we want machines to follow referrals we have to provide them in
> >appropriate forms.
>
> 
> I've set up .ws.sp.am (that's ws for Whois Server) which is
> updated every day from a variety of sources so it's pretty accurate.
> It's had the right server for pro.ws.sp.am all along.
>

Hey, that's fantastic!

Feature request: could you provide a human- and machine-readable one-stop
extract at the top-level page (ws.sp.am) ?

Royce

Re: Facebook & Traceroute

[Christopher Morrow]

On Wed, Mar 9, 2016 at 11:22 PM, Sam Norris  wrote:
>> maybe their loadbalancer is a little wonky? (I don't see this in
>> traceroutes from a few places, but I also don't end up at IAD for
>> 'www.facebook.com' traceroutes... here's my last 4 hops though to the
>> dest-ip you had:
>>
>> .13.28.75)  0.597 ms ae0.dr08.ash2.tfbnw.net (31.13.26.235)  0.576 ms
>>  8  * * *
>>  9  * * *
>> 10  * * *
>> 11  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  0.774 ms
>> 0.755 ms  0.701 ms
>
> This is probably because you are properly filtering your own prefixes from 
> being sourced outside coming in?
>

unclear, that traceroute was from someplace I don't own the network for...
from another place I do though...

 5  ae0.dr07.ash2.tfbnw.net (31.13.26.233)  4 ms
ae0.dr05.ash3.tfbnw.net (31.13.29.21)  4 ms ae0.dr08.ash2.tfbnw.net
(31.13.26.235)  2 ms
 6  * * *
 7  * * *
 8  * * *
 9  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  3 ms  3 ms  2 ms

same-ish results, no spoofed bits.

Re: AW: Cogent - Google - HE Fun

[Christopher Morrow]

On Thu, Mar 10, 2016 at 10:09 AM, Dennis Burgess
 wrote:
> Not wishing to get into a pissing war with who is right or wrong, but it 
> sounds like google already pays or has an agreement with cogent for v4, as 
> that's unaffected, cogent says google is simply not advertising v6 prefixes 
> to them, so, how is that cogent's fault?
>

Did you check that on Cogent's LookingGlass?

"BGP routing table entry for 216.239.32.0/24, version 3740382954
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  6453 15169
154.54.13.206 (metric 10102020) from 154.54.66.21 (154.54.66.21)
  Origin IGP, metric 4294967294, localpref 100, valid, internal, best
  Community: 174:10031 174:20666 174:21000 174:22013
  Originator: 66.28.1.9, Cluster list: 154.54.66.21"

is a lookup on: http://www.cogentco.com/en/network/looking-glass

if 216.239.32.0 - which holds ns1.google.com... I'd expect that
ns1.google.com would be routed via the majority of links 15169 has
with the world.

>
> -Original Message-
> From: Jon Lewis [mailto:jle...@lewis.org]
> Sent: Wednesday, March 9, 2016 11:26 AM
> To: Jürgen Jaritsch 
> Cc: Dennis Burgess ; North American Network 
> Operators' Group 
> Subject: Re: AW: Cogent - Google - HE Fun
>
> In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm 
> not surprised.  I suggested it during talks with GOOG roughly 10 years 
> ago...not saying I had any influence...I'm pretty sure I did not. :)
>
> GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them 
> or someone else to get to Cogent).  If you're well peered / multihomed, it's 
> not much of an issue.  If you're a single-homed Cogent customer, you should 
> complain to Cogent that they're not providing full
> IPv6 connectivity.
>
> On Wed, 9 Mar 2016, Jürgen Jaritsch wrote:
>
>> Hi,
>>
>> mail from Cogent:
>>
>> Dear Cogent Customer,
>>
>> Thank you for contacting Cogent Customer Support for information about the 
>> Google IPv6 addresses you are unable to reach.
>>
>> Google uses transit providers to announce their IPv4 routes to Cogent.
>>
>> At this time however, Google has chosen not to announce their IPv6 routes to 
>> Cogent through transit providers.
>>
>> We apologize for any inconvenience this may cause you and will notify you if 
>> there is an update to the situation.
>> 
>>
>> Mail from Google:
>>
>> Unfortunately it seems that your transit provider does not have IPv6 
>> connectivity with Google. We suggest you ask your transit provider to look 
>> for alternatives to interconnect with us.
>>
>> Google maintains an open interconnect policy for IPv6 and welcomes any 
>> network to peer with us for access via IPv6 (and IPv4). For those networks 
>> that aren't able, or chose not to peer with Google via IPv6, they are able 
>> to reach us through any of a large number of transit providers.
>>
>> For more information in how to peer directly with Google please visit
>> https://peering.google.com 
>>
>> best regards
>>
>> Jürgen Jaritsch
>> Head of Network & Infrastructure
>>
>> ANEXIA Internetdienstleistungs GmbH
>>
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>>
>> E-Mail: jjarit...@anexia-it.com
>> Web: http://www.anexia-it.com
>>
>>
>>
>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020
>> Klagenfurt
>> Geschäftsführer: Alexander Windbichler
>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT
>> U63216601
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: NANOG [mailto:nanog-bounces+jjaritsch=anexia-it@nanog.org] Im
>> Auftrag von Dennis Burgess
>> Gesendet: Mittwoch, 09. März 2016 17:01
>> An: North American Network Operators' Group
>> Betreff: Cogent - Google - HE Fun
>>
>> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at 
>> all. I was told google pulled all of their peering with Cogent?   If I bring 
>> up a SIT tunnel with HE, I get the prefixes but at horrible speed and 
>> latency .. anyone else?
>>
>> [DennisBurgessSignature]
>> www.linktechs.net - 314-735-0270 x103 -
>> dmburg...@linktechs.net
>>
>>
>
> --
>   Jon Lewis, MCP :)   |  I route
>   |  therefore you are _ 
> http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: AW: Cogent - Google - HE Fun

[Jon Lewis]

My guess is that GOOG is playing peering chicken with Cogent on "the IPv6 
Internet" because doing so is low impact.  Doing this with v4 routing 
would be far more painful to both GOOG and single-homed Cogent customers 
(probably make the news and make one or both look bad).  Doing this with 
v6 keeps it off in the shadows...both parties know its an issue, but its 
likely not seriously impacting anyone yet.  GOOG likely thinks they're big 
enough and their content desirable enough, that Cogent should peer with 
them.  Cogent clearly disagrees.  I'm sure GOOG would prefer SFI with 
Cogent for v4 and v6...but they're working on getting v6 first.


On Thu, 10 Mar 2016, Dennis Burgess wrote:


Not wishing to get into a pissing war with who is right or wrong, but it sounds 
like google already pays or has an agreement with cogent for v4, as that's 
unaffected, cogent says google is simply not advertising v6 prefixes to them, 
so, how is that cogent's fault?


-Original Message-
From: Jon Lewis [mailto:jle...@lewis.org]
Sent: Wednesday, March 9, 2016 11:26 AM
To: Jürgen Jaritsch 
Cc: Dennis Burgess ; North American Network Operators' Group 

Subject: Re: AW: Cogent - Google - HE Fun

In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm not 
surprised.  I suggested it during talks with GOOG roughly 10 years ago...not 
saying I had any influence...I'm pretty sure I did not. :)

GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them or 
someone else to get to Cogent).  If you're well peered / multihomed, it's not 
much of an issue.  If you're a single-homed Cogent customer, you should 
complain to Cogent that they're not providing full
IPv6 connectivity.

On Wed, 9 Mar 2016, Jürgen Jaritsch wrote:


Hi,

mail from Cogent:



Dear Cogent Customer,

Thank you for contacting Cogent Customer Support for information about the 
Google IPv6 addresses you are unable to reach.

Google uses transit providers to announce their IPv4 routes to Cogent.

At this time however, Google has chosen not to announce their IPv6 routes to 
Cogent through transit providers.

We apologize for any inconvenience this may cause you and will notify you if 
there is an update to the situation.


Mail from Google:



Unfortunately it seems that your transit provider does not have IPv6 
connectivity with Google. We suggest you ask your transit provider to look for 
alternatives to interconnect with us.

Google maintains an open interconnect policy for IPv6 and welcomes any network 
to peer with us for access via IPv6 (and IPv4). For those networks that aren't 
able, or chose not to peer with Google via IPv6, they are able to reach us 
through any of a large number of transit providers.

For more information in how to peer directly with Google please visit
https://peering.google.com 

best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jjarit...@anexia-it.com
Web: http://www.anexia-it.com



Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020
Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT
U63216601


-Ursprüngliche Nachricht-
Von: NANOG [mailto:nanog-bounces+jjaritsch=anexia-it@nanog.org] Im
Auftrag von Dennis Burgess
Gesendet: Mittwoch, 09. März 2016 17:01
An: North American Network Operators' Group
Betreff: Cogent - Google - HE Fun

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. 
I was told google pulled all of their peering with Cogent?   If I bring up a 
SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. 
anyone else?

[DennisBurgessSignature]
www.linktechs.net - 314-735-0270 x103 -
dmburg...@linktechs.net




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



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

RE: AW: Cogent - Google - HE Fun

[Dennis Burgess]

Not wishing to get into a pissing war with who is right or wrong, but it sounds 
like google already pays or has an agreement with cogent for v4, as that's 
unaffected, cogent says google is simply not advertising v6 prefixes to them, 
so, how is that cogent's fault?


-Original Message-
From: Jon Lewis [mailto:jle...@lewis.org] 
Sent: Wednesday, March 9, 2016 11:26 AM
To: Jürgen Jaritsch 
Cc: Dennis Burgess ; North American Network Operators' 
Group 
Subject: Re: AW: Cogent - Google - HE Fun

In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm not 
surprised.  I suggested it during talks with GOOG roughly 10 years ago...not 
saying I had any influence...I'm pretty sure I did not. :)

GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from them or 
someone else to get to Cogent).  If you're well peered / multihomed, it's not 
much of an issue.  If you're a single-homed Cogent customer, you should 
complain to Cogent that they're not providing full
IPv6 connectivity.

On Wed, 9 Mar 2016, Jürgen Jaritsch wrote:

> Hi,
>
> mail from Cogent:
>
> Dear Cogent Customer,
>
> Thank you for contacting Cogent Customer Support for information about the 
> Google IPv6 addresses you are unable to reach.
>
> Google uses transit providers to announce their IPv4 routes to Cogent.
>
> At this time however, Google has chosen not to announce their IPv6 routes to 
> Cogent through transit providers.
>
> We apologize for any inconvenience this may cause you and will notify you if 
> there is an update to the situation.
> 
>
> Mail from Google:
>
> Unfortunately it seems that your transit provider does not have IPv6 
> connectivity with Google. We suggest you ask your transit provider to look 
> for alternatives to interconnect with us.
>
> Google maintains an open interconnect policy for IPv6 and welcomes any 
> network to peer with us for access via IPv6 (and IPv4). For those networks 
> that aren't able, or chose not to peer with Google via IPv6, they are able to 
> reach us through any of a large number of transit providers.
>
> For more information in how to peer directly with Google please visit 
> https://peering.google.com 
>
> best regards
>
> Jürgen Jaritsch
> Head of Network & Infrastructure
>
> ANEXIA Internetdienstleistungs GmbH
>
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
>
> E-Mail: jjarit...@anexia-it.com
> Web: http://www.anexia-it.com
>
>
>
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 
> Klagenfurt
> Geschäftsführer: Alexander Windbichler
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT 
> U63216601
>
>
> -Ursprüngliche Nachricht-
> Von: NANOG [mailto:nanog-bounces+jjaritsch=anexia-it@nanog.org] Im 
> Auftrag von Dennis Burgess
> Gesendet: Mittwoch, 09. März 2016 17:01
> An: North American Network Operators' Group
> Betreff: Cogent - Google - HE Fun
>
> I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at 
> all. I was told google pulled all of their peering with Cogent?   If I bring 
> up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency 
> .. anyone else?
>
> [DennisBurgessSignature]
> www.linktechs.net - 314-735-0270 x103 - 
> dmburg...@linktechs.net
>
>

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

Re: Internet Exchanges supporting jumbo frames?

[Joel Maslak]

On Wed, Mar 9, 2016 at 9:27 AM, joel jaeggli  wrote:

> PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in
> > my opinion (although it's strange how many hosts that seem to get away
> > with 1492 (or is it 1496) MTU because they're using PPPoE).
>
> if your adv_mss is set accordingly you can get away with
>  a lot.
>

At least for TCP.  EDNS with sizes > 14xx bytes just plain doesn't
universally work across the internet, yet it's the default everywhere.

Re: Internet Exchanges supporting jumbo frames?

[Tassos Chatzithomaoglou]

Martin Pels wrote on 10/3/2016 4:15 μμ:
> On Thu, 10 Mar 2016 08:23:30 +0200
> Tassos Chatzithomaoglou  wrote:
>
>> Niels Bakker wrote on 10/3/16 02:44:
>>> * nanog@nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59
>>> CET]:
 I'm pretty confident there is no need for a specific MTU consensus
 and not all IXP participants are obligated to raise their
 interface MTU if the IXP starts allowing jumbo frames.
>>> You're wrong here.  The IXP switch platform cannot send ICMP Packet
>>> Too Big messages.  That's why everybody must agree on one MTU.
>>>
>>>
>> Isn't that the case for IXP's current/default MTU?
>> If an IXP currently uses 1500, what effect will it have to its
>> customers if it's increased to 9200 but not announced to them?
> None. Until someone actually tries to make use of the higher MTU. Then
> things start breaking.
>

I can understand the above issue. But as i said that's customer's decision.
Exactly the same will happen if the customer increases its mtu now.
> In order for Jumboframes to be successful on IXPs _on a large scale_
> the technology has to change. There needs to be a mechanism to negotiate
> MTU for each L2 neighbor individually. Something like
> draft-van-beijnum-multi-mtu-03, which was mentioned before in this
> thread. With this in place individual sets of peers could safely use
> different MTUs on the same VLAN, and IXPs would have a migration path
> towards supporting larger framesizes.

Agreed. But that doesn't forbid the IXPs to use the max MTU now.


--
Tassos

Re: finding whois servers, was .pro whois registry down?

[John Levine]

>   _whois._tcp.pro. srv 0 100 43 whois.afilias.net.

A swell idea, but unfortunately the idea of putting SRV records in
gTLD zones makes heads at ICANN explode.  For RDAP there's a registry
at IANA but it's not populated yet and it's not obvious that registries
will be any more diligent about updating it than they are for the WHOIS
entries in the TLD database.

>If we want machines to follow referrals we have to provide them in
>appropriate forms.

.ws.sp.am (that's ws for Whois Server) which is
updated every day from a variety of sources so it's pretty accurate.
It's had the right server for pro.ws.sp.am all along.

R's,
John

Re: Internet Exchanges supporting jumbo frames?

[Mike Hammett]

Until you've ran an IXP, you have no idea how finicky or clueless some network 
operators are. 




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



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Nick Hilliard"  
To: "Saku Ytti"  
Cc: "NANOG list"  
Sent: Wednesday, March 9, 2016 1:46:54 PM 
Subject: Re: Internet Exchanges supporting jumbo frames? 

Saku Ytti wrote: 
> If customer does not react, put it on quarantine VLAN. This can be 
> automated too. Wrong MTU => open internal case, contact customers 
> email, no customer response in N days, quarantine VLAN. 

... and then the customer will leave the service down because it the 
primary peering lan works fine and they couldn't be bothered fixing 
jumbo lan connectivity because the neteng who wanted the 9000 byte mtu 
connectivity in the first place got distracted by a squirrel or left the 
company or was too busy doing other things. 

> work, but it's very difficult to actually know without trying what 
> works and what does. 

I've spent a good deal of time and effort trying to get a jumbo peering 
vlan to work and it didn't work for the reasons that I've mentioned, and 
others. 

For example, many types of hardware don't allow you to specify a 
different MTU for different .1q tags on the same physical interface. 
This means that if you want a connection to a jumbo MTU vlan and a 
standard mtu vlan, you needed two separate connections into the IXP. At 
that point, the ixp participant is unlikely to want to bother because 
there's no cost:value justification in getting the second connection. 

Don't get me wrong: jumbo MTU IXPs are a great idea in theory. In 
practice, they cause an inordinate amount of pain. 

Nick 

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

[Tony Finch]

Mark Andrews  wrote:
>
> Additionally 'whois' is free form text.  Whois doesn't include a
> AI to workout what this free form text means so, no, there isn't a
> actual referral for a whois application to use.

Yes, the whois data format is bullshit, but there are only a few simple
referral patterns in use, so in practice following referrals works OK.

> Additionally we should be publishing where the whois server for the
> tld is in the DNS.

>   _whois._tcp.pro. srv 0 100 43 whois.afilias.net.

That would be nice, but in practice the requirement is a whois.nic.TLD
host rather than a SRV record. And we don't really need yet another way
to find whois servers - we already have more than enough.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Humber, Thames: East or southeast 3 or 4. Slight. Mainly fair. Moderate or
good.

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 10 March 2016 at 02:44, Niels Bakker