Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[William Herrin]

On Thu, Jan 28, 2016 at 8:45 AM, Randy Bush  wrote:
> folk can rant on nanog all they want if it
> makes them feel good or self-righteous.

Hi Randy,

It DOES make me feel good. And a little self-righteous.

>  won't change a damned thing.

Some FCC employees read this forum. My impression is that they're not
terribly far from concluding that closed peering policies are
anti-competitive. When I have such impressions I'm usually off by
years. Still, it would be nice if just once an industry cleaned itself
up -before- regulators forced the issue.

Regards,
Bill Herrin


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

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Owen DeLong]

> While I do not disagree that larger providers looking to protect their
> revenues is an economically-sound objective, I think the typical peering
> policies of old do not entirely hold up in 2016.

I’m pretty convinced that they never really did. I realize they’ve been popular
conventional wisdom for some time now, but that was brought about when Telcos
started being the dominant players in the ISP market and I always regarded it
as an artifact of “carrier mentality” where they were so used to the settlement
mechanisms of the traditional telephone network.

The reality is that the traditional telephone network has been getting slowly
superseded by the internet largely because of the differences in the settlement
model. If TDM and its settlement model were cheaper than VOIP, there would be
little reason to spend money deploying VOIP. Unified communications has some
benefits, but not really enough in most real world implementations to overcome
the costs if it wasn’t reducing the corporate phone-spend.

For many years, telcos tried all kinds of strange things and in some remote
regions these are still happening. For example in some places, they sought
regulatory protection of their “right to revenue” for voice calls by actually
getting laws against VOIP services and the like. Those laws still exist in
some areas and their economies are suffering for it.

Bottom line, I’ve never seen a case where any ISP has definitively benefited
from a restrictive peering policy. At best, it’s a neutral factor that most
people just sort of accept. Routinely, it drives business away from such
ISPs towards Tier-2s with good transit relationships and a better peering
policy. At worst, I’ve seen it create active bad will in various communities
as is the current case with Cogent and is a demonstrable factor in the
decline of SPRINT.

Owen

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Måns Nilsson]

Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
Electric - and how to solve it Date: Wed, Jan 27, 2016 at 05:36:13PM -0800 
Quoting Owen DeLong (o...@delong.com):
> 
> > On Jan 27, 2016, at 14:43 , Måns Nilsson  wrote:
> > 
> > Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
> > Electric - and how to solve it Date: Fri, Jan 22, 2016 at 12:28:01PM + 
> > Quoting Brandon Butterworth (bran...@rd.bbc.co.uk):
> > 
> >> tier 1 seems consistent with Cogents refusal.
> > 
> > one does not become a tier 1 by refusing to peer. an actual tier 1 will
> > of course most of the time refuse  settlement-free interconnection with
> > smaller actors to protect their revenue stream, but the traffic volumes
> > and short settlement-free paths to large parts of the Internet are what
> > make them a tier-1.
> 
> I disagree with this last part.
 
So do I, actually. I was just reporting what Tier-1 operators might feel be 
good for business.  Not that I believe that they're right. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
On SECOND thought, maybe I'll heat up some BAKED BEANS and watch REGIS
PHILBIN ...  It's GREAT to be ALIVE!!


signature.asc
Description: Digital signature

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Randy Bush]

almost all top tier providers have closed peering policies, many
outright draconian.  folk can rant on nanog all they want if it
makes them feel good or self-righteous.  won't change a damned
thing.  bunch of whiners, whining about something that has been
a reality for over 20 years and is not about to change.

but like spam, nanog bandwidth is cheap.  so rant away.

randy

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Owen DeLong]

Sadly, the law firms with big routers seem to prefer a regulatory environment 
that they
can manipulate, so it’s a tough situation to achieve a good outcome.

They are the ones that are blocking the industry from arriving at a good 
outcome without
regulation and they will likely be the ones driving regulation in ridiculous 
directions
away from good outcomes once we start to see regulation.

The way lawyers redefine terms and obfuscate to make regulations say what they 
want instead
of what any normal person would think they actually say is truly impressive.

Owen

> On Jan 28, 2016, at 18:01 , Mike Hammett  wrote:
> 
> Nothing says a better Internet than one the government pokes their nose 
> around in. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "William Herrin"  
> To: "Randy Bush"  
> Cc: "North American Network Operators' Group"  
> Sent: Thursday, January 28, 2016 5:25:47 PM 
> Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
> Electric - and how to solve it 
> 
> On Thu, Jan 28, 2016 at 8:45 AM, Randy Bush  wrote: 
>> folk can rant on nanog all they want if it 
>> makes them feel good or self-righteous. 
> 
> Hi Randy, 
> 
> It DOES make me feel good. And a little self-righteous. 
> 
>> won't change a damned thing. 
> 
> Some FCC employees read this forum. My impression is that they're not 
> terribly far from concluding that closed peering policies are 
> anti-competitive. When I have such impressions I'm usually off by 
> years. Still, it would be nice if just once an industry cleaned itself 
> up -before- regulators forced the issue. 
> 
> Regards, 
> Bill Herrin 
> 
> 
> -- 
> William Herrin  her...@dirtside.com b...@herrin.us 
> Owner, Dirtside Systems . Web:  

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mike Hammett]

Nothing says a better Internet than one the government pokes their nose around 
in. 




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

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "William Herrin"  
To: "Randy Bush"  
Cc: "North American Network Operators' Group"  
Sent: Thursday, January 28, 2016 5:25:47 PM 
Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
Electric - and how to solve it 

On Thu, Jan 28, 2016 at 8:45 AM, Randy Bush  wrote: 
> folk can rant on nanog all they want if it 
> makes them feel good or self-righteous. 

Hi Randy, 

It DOES make me feel good. And a little self-righteous. 

> won't change a damned thing. 

Some FCC employees read this forum. My impression is that they're not 
terribly far from concluding that closed peering policies are 
anti-competitive. When I have such impressions I'm usually off by 
years. Still, it would be nice if just once an industry cleaned itself 
up -before- regulators forced the issue. 

Regards, 
Bill Herrin 


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

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 28/Jan/16 11:16, Owen DeLong wrote:

> Bottom line, I’ve never seen a case where any ISP has definitively benefited
> from a restrictive peering policy. At best, it’s a neutral factor that most
> people just sort of accept. Routinely, it drives business away from such
> ISPs towards Tier-2s with good transit relationships and a better peering
> policy. At worst, I’ve seen it create active bad will in various communities
> as is the current case with Cogent and is a demonstrable factor in the
> decline of SPRINT.

Agree.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Owen DeLong]

> On Jan 27, 2016, at 14:43 , Måns Nilsson  wrote:
> 
> Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
> Electric - and how to solve it Date: Fri, Jan 22, 2016 at 12:28:01PM + 
> Quoting Brandon Butterworth (bran...@rd.bbc.co.uk):
> 
>> tier 1 seems consistent with Cogents refusal.
> 
> one does not become a tier 1 by refusing to peer. an actual tier 1 will
> of course most of the time refuse  settlement-free interconnection with
> smaller actors to protect their revenue stream, but the traffic volumes
> and short settlement-free paths to large parts of the Internet are what
> make them a tier-1.

I disagree with this last part.

I realize that the common wisdom among execs at so-called tier-1 providers
is that refusing SFI protects their revenue stream, but I believe it’s not
true.

In fact, I think that a willingness to peer with your customers and anyone
else on the internet wherever you can do so for very little cost (for example,
where it’s just one more peering session at an IXP, no additional port cost,
circuit, XC, etc.) settlement free can only increase your business.

IMHO, a truly good tier-1 will charge for transit, set their metrics and
prefs such that their paid ports are preferred over their non-revenue
ports, and provides peer routes only on the SFIs.

This turns out to be mostly a win-win situation for everyone, including the
tier-1 in the long run.

OTOH, look what happened to SPRINT when they went on their depeering binge.
They went from the cat-bird seat of being the top Tier-1 provider on the
planet to the modern day status of “also ran”.

I suspect the only reason Cogent isn’t losing ground as fast as SPRINT
did has to do with two things:

1.  They aren’t turning off existing peers as aggressively as
SPRINT did.

2.  They have the cheapest transit prices of just about anyone
except possibly HE (why they are in a race to the bottom with).

However, even at their current rate, this will likely catch up with them
sooner or later and cause them some discomfort.

YMMV.

Owen

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Måns Nilsson]

Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
Electric - and how to solve it Date: Fri, Jan 22, 2016 at 12:28:01PM + 
Quoting Brandon Butterworth (bran...@rd.bbc.co.uk):
 
> tier 1 seems consistent with Cogents refusal.

one does not become a tier 1 by refusing to peer. an actual tier 1 will
of course most of the time refuse  settlement-free interconnection with
smaller actors to protect their revenue stream, but the traffic volumes
and short settlement-free paths to large parts of the Internet are what
make them a tier-1.

do you hear me, medium-sized swedish  isp full of clued people but with
a serious case of peering reality distorsion?

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Can you MAIL a BEAN CAKE?


signature.asc
Description: Digital signature

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 28/Jan/16 03:36, Owen DeLong wrote:

> I disagree with this last part.
>
> I realize that the common wisdom among execs at so-called tier-1 providers
> is that refusing SFI protects their revenue stream, but I believe it’s not
> true.
>
> In fact, I think that a willingness to peer with your customers and anyone
> else on the internet wherever you can do so for very little cost (for example,
> where it’s just one more peering session at an IXP, no additional port cost,
> circuit, XC, etc.) settlement free can only increase your business.
>
> IMHO, a truly good tier-1 will charge for transit, set their metrics and
> prefs such that their paid ports are preferred over their non-revenue
> ports, and provides peer routes only on the SFIs.
>
> This turns out to be mostly a win-win situation for everyone, including the
> tier-1 in the long run.

I tend to agree with Owen on this one.

We, last year, transitioned from selective to open peering - despite our
scope - in the region we serve (primarily Africa). It has only improved
the quality of our service (a great deal of Africa still exchanges
traffic in Europe), lowered costs, made customers happy and generated a
lot of community goodwill.

Obviously, we do not provide free transit across SFI ports, and we have
practical implementations in place to ensure that we only handle
customer traffic through customer-facing links, removing the potential
of handling customer traffic through peering links (particularly with
customers who are multi-homed to you and another SFI peer of yours).

While I do not disagree that larger providers looking to protect their
revenues is an economically-sound objective, I think the typical peering
policies of old do not entirely hold up in 2016.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Job Snijders]

On Wed, Jan 27, 2016 at 09:11:59AM -0500, jimmy keffer wrote:
> does ntt peer with he for ip6?

You can review sites like:


https://radar.qrator.net/as2914/ipv6-peerings#startDate=2015-10-10=2016-01-27=current

or

http://bgp.he.net/AS2914#_peers6

to get a sense of what relations exist.

Kind regards,

Job

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[jimmy keffer]

does ntt peer with he for ip6?

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[joel jaeggli]

On 1/25/16 11:06 AM, Jared Mauch wrote:
> My understanding is this was mostly legacy from devices that did not
> carry full Rib and fib. There were tricks to avoid ending up on these
> skinny devices if you wanted.
> 
> Life in the core has changed a lot in recent years from 6500/7600 and
> foundry/brocade class devices to a more interesting set in the
> pipeline or released.
> 
> There are some limited rib-> fib download boxes that could slice
> traffic in cost effective ways that the price conscious consumer will
> likely push the market to.

There are also of course variations on this. An an aggregation router
may have quite limited FIB, e.g. enough for customer routes yet still
have a full rib in it's control-plane, at which point it needs to
default towards devices which do have a FIB in place.  assuming a single
hob peering it would be rather hard to identify this case as a customer,
though if your neighbor has an Arista mac address for example that might
be a logical conclusion.

> Jared Mauch
> 
>> On Jan 22, 2016, at 3:28 PM, Joe Maimon  wrote:
>> 
>> 
>> I have a pending request to get that multi-hop setup. I was told
>> that it was now a special request and they would "try" to get it
>> done and these days all their routers had full table capacity and
>> they no longer used the multi-hop.
> 




signature.asc
Description: OpenPGP digital signature

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 27/Jan/16 09:31, joel jaeggli wrote:

> > > There are also of course variations on this. An an aggregation
router > may have quite limited FIB, e.g. enough for customer routes yet
still > have a full rib in it's control-plane, at which point it needs
to > default towards devices which do have a FIB in place.  assuming a
single > hob peering it would be rather hard to identify this case as a
customer, > though if your neighbor has an Arista mac address for
example that might > be a logical conclusion.

In all our Metro-E deployments, where we have enough RIB to hold
multiple full feeds, but a limited FIB for forwarding, there is no
discernible difference in performance both at the routing and forwarding
levels to our customers that take full BGP feeds natively from these
devices.

Mark.
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJWqHPKAAoJEGcZuYTeKm+GgPgP/2v9PaX7cfg7re6jAhbbWkzp
sw5jsPdF0eCmJAOICvv74ZymRzW8fAmlt98XWpmAJh/8WqDKkn/H1lEt1hvsyuYE
9PC3PRsT2+Qhb26Erlz1LB+95dS6PzZyNzHC6YRRbB2j3aZkazkOHCZTl4lWZeIP
ZsiafWQl3LDCUOrgO4JsqVg3r4D4DhMATKxQuP5siXOiEpwVk1zWSa+MfydrUrg7
jlGzwkH1Igh1UmsMy2oSW9azjQizSyBl6/fdbx3sbCHqHrtXbAt7TSrF0kJ//1lm
JHYhGM1vovpxKCOxY74AiemrSXFbkDCSc8LgiMRPL3l5VfquYVy6jXFpiPM/H9sU
xKUS3uKEJ4IgIIl6URMfusWTirmPC6f7mvqwOGNn/qabU4AKq+WsPshFMfb3+9Ry
v0+3/o3i/hNOc+neL6oE8mHZ24pilbKltCYFD7pPTKS8lROoXfaHv4d52FMXPMUL
oqdvLtRYjSb5RXpkX5hzMzJkqKJ5oVIm+Oj+KP4ekiNGRedEgiEfAPcwJG54NQgv
M8Ji8cgAfwcd2lhIZXfDg1y7N4Jl5k48C1KBJV0y6nPFjtonqrufW7PEUWX17dqq
ih0pcvy4dAv81hSY9jdRJucS/Kev3xLbikRA5f8vHN4h9jH7OnXh4VNrCXnetUb5
VhtsoJ6/yiz/PKJ/zEu4
=QPdU
-END PGP SIGNATURE-

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Randy Bush]

> IXPs solve a different set of problems, namely how to interconnect with
> large numbers of third party organisations with low admin overhead.

and low port count

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Randy Bush]

> It appears that to route on the edge with multihop is viewed as novel.

might have been novel in 1990, not now.  other adjectives apply, and not
nice ones

randy

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Justin Wilson]

From an IX perspective HE is much more receptive to peering at an IX. Last I 
knew cogent outright says no.  In our Indianapolis market a ton of capacity 
would be saved if Cogent would peer.  I understand the reasoning, but having a 
provider that is more willing to peer is a draw to the end user networks we 
work with.



Justin Wilson
j...@mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting – Data Centers - Bandwidth

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

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 25/Jan/16 23:01, Joe Maimon wrote:

>
>  
> Before BFD, we had keepalives right in BGP. Whats wrong with that?

You may want to signal failure more quickly than BGP's own timers can
handle.


>
> I suppose you also advocate that each provider use a phy port directly
> on the ege, no switches in between, so that the full table can be
> yanked out as quickly as possible and that it be flooded back in as
> soon as possible, as many times as possible...

Not how I run my network. I aggregate customer ports to a Layer 2
switch, which upstreams to the edge router for service. Router ports are
expensive.

The only time I'll terminate customer links to a router is if they are
buying 100Gbps native services.


>
>
> The question is whether it is a reality for gear that already cannot
> support full tables (likely EoS), or that is projected not to support
> them in the future. And which is practical to obtain and operate.

If your gear does not have the latest capabilities, then using what it
has to achieve the best possible outcome is a well understood strategy.

What we are talking about here is options in current state-of-the-art
that you would want to ignore for older options if you have the
opportunity not to. But, your network, your rules.


>
> Further, FIB is one part. Collecting multiple full tables can also
> impose a dram burden on an edge router.
>
> And churn on its CPU. Crypto, policy, etc.
>
> Lets face it. An edge device control processor and memory is not the
> ideal location for all this. It does not compare with the GP hardware
> available for that task and it never will.

Not from what I see in my network.

I have virtual routers running on x86_64 servers chugging along just as
well as the routing engines on my Juniper and Cisco edge routers.
Admittedly, the control planes in those routers are high-end, and I
can't expect that everyone can afford them, but to say the brains in
modern routers are not up to the task is simply not true. In fact, the
control plane on some of these boxes is not yet being fully exploited
because code is still slowly evolving to take advantage of multi-core
architecture, and 64-bit memory, particularly for routing processes. The
headroom and performance on these has been phenomenal, and I can take
that to the bank.


>
>
> Who says it must be that way? You could go the other extreme, it is
> quite feasible to have multiple RR's per pop (if thats what you want)
> and you can even segregate each eBGP feed into its own BGP router
> process, using a fraction of the hardware resources available to you
> in todays 1U server, available at a fraction of the cost of
> yesterday's edge.
>
> It is not too hard to see that this approach offers a degree of design
> freedom that coupling your ebgp directly to your edge does not.

Not the way I'd do it, but like I said, your network, your rules.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 26/Jan/16 08:34, Joe Maimon wrote:

>  
>
> I dont want to churn a full table any quicker then BGP timers.

You don't have to churn the whole table, you just have to churn the
(indirect) next-hop.


> And if you choose to run that ebgp loopback multihop on the same
> router, you can track routes and interfaces in realtime, to the extent
> your CP SW supports it. Choice is yours.

This feature is not unique to eBGP Multi-Hop.

Search for Next-Hop Address Tracking and/or Indirect Next-Hop.


>
> That was my point. Phy signalling is easily and often sacrificed for
> density and flexibility.

We have not had to sacrifice performance with our customers in these
types of topologies.

In the Metro, BGP sessions instantiate directly on the Ethernet switch,
so we don't lose performance there either.


>
> To return to the topic on hand, Cogent seemed to do quite well in the
> transit wars with this approach. So perhaps there is something to it.

It allowed them to use cheap switches in the Access. That makes a lot of
difference when you're undercutting the competition.

In 2016, you can still use cheap switches to keep your Access costs
down, but you don't have to sacrifice edge-based BGP routing if it's
your thing.


>
> Maybe they were not constrained by the pricing for the gear with the
> latest capabilities and capacities as their competitors were? Perhaps
> this approach enabled them to more rapidly build out and light up
> their network to catch up to their competitors, to the point that they
> now sound more like them than they do their previous selves?

Yes, and yes.

Cheap switches that you can deploy rapidly make for a good business case.


>
> Or better?

Not necessarily.

I can hold more tables because the servers have 512GB of RAM, but won't
because the code can only address 16GB max. today (some of which goes to
the code itself at boot). Work in progress, the code started at 4GB only
last year, so we'll get there.

CPU performance also still needs to get better. 12x cores in the
chassis, but because of code limitations, they aren't yet fully optimized.

Overall, still better than using a dedicated router for RR functions.


> And how do those routers get their full tables to munch on?

From a bunch of purpose-built edge, peering and border routers.


>
> What I said is that they do not compare. Or is the control plane
> hardware specs in the latest and greatest C/J box identical to what
> you would be getting for the latest and greatest x86_64 server? My,
> times have changed.

My Juniper routers are running x86_64-based 1.8GHz Quad-Core CPU's with
16GB of RAM. 32GB RAM options are now available.

Not cheap, but with several full IPv4/IPv6 views, dozens of customers
taking full feeds, I am not struggling for grunt.

As Junos gets cleverer, those additional cores will come to life
(fingers crossed).


>
>
> Are you saying that the control plane experience lags behind general
> purpose computing?

Nope - I'm saying if you have some cash to burn, you're now in a
position where one option is not automatically better than the other.

I use servers with virtual routers for my RR's because the prospect of
sticking 1TB of RAM in a router is not yet feasible. At the same time,
I'm comfortable running BGP natively in the edge because the control
planes on the routers I have are nowhere near saturation, running tech.
2x years old now.


>
> Simply because you can afford the inflated pricing of the latest and
> greatest gear does not mean you should and it also does not mean the
> techniques available and in use to do so are in and of themselves
> suspect. No matter the temptation to do so.

Agree, but BGP routing is not the only reason we need the control planes.

There are other elements to our business that drive that spec.


>
> To a certain extent, the market for the hardware probably accounts for
> and takes advantage of any such unwillingness to engineer around cost,
> whether it is due to pure design concerns or tinged with psychological
> suggestion.

We spend if we have to, and don't if we don't have to.

For our RR deployment, for example, it was either dedicated routers for
the task, or a long-term view on servers + a hypervisor. We chose the
latter.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 26/Jan/16 00:28, Brandon Butterworth wrote:

> Doesn't matter, if traffic is blackholed at an ix then it
> won't be failing over to another one. Same effect

Route servers do not participating in the forwarding plane. If they
fail, you lose routes from that exchange point which show up elsewhere.

If peers are originating routes at exchange points and lose their
backhauls, that's another set of problems your NOC can fix.

If the exchange point switch runs out of ideas, that's another set of
problems your NOC can fix.


> The general case doesn't care about your network, it assumes you'd
> engineer that appropriately for the criticality and do something
> different/better if you need to.

Big assumption to make.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Joe Maimon]

Mark Tinka wrote:






You may want to signal failure more quickly than BGP's own timers can
handle.


I dont want to churn a full table any quicker then BGP timers. And if 
you choose to run that ebgp loopback multihop on the same router, you 
can track routes and interfaces in realtime, to the extent your CP SW 
supports it. Choice is yours.




Not how I run my network. I aggregate customer ports to a Layer 2
switch, which upstreams to the edge router for service. Router ports are
expensive.


That was my point. Phy signalling is easily and often sacrificed for 
density and flexibility.



If your gear does not have the latest capabilities, then using what it
has to achieve the best possible outcome is a well understood strategy.


And when you can use a design that offers advantages either way, so much 
the better.


To return to the topic on hand, Cogent seemed to do quite well in the 
transit wars with this approach. So perhaps there is something to it.


Maybe they were not constrained by the pricing for the gear with the 
latest capabilities and capacities as their competitors were? Perhaps 
this approach enabled them to more rapidly build out and light up their 
network to catch up to their competitors, to the point that they now 
sound more like them than they do their previous selves?




I have virtual routers running on x86_64 servers chugging along just as
well as the routing engines on my Juniper and Cisco edge routers.


Or better? And how do those routers get their full tables to munch on?


Admittedly, the control planes in those routers are high-end, and I
can't expect that everyone can afford them, but to say the brains in
modern routers are not up to the task is simply not true.


What I said is that they do not compare. Or is the control plane 
hardware specs in the latest and greatest C/J box identical to what you 
would be getting for the latest and greatest x86_64 server? My, times 
have changed.




In fact, the
control plane on some of these boxes is not yet being fully exploited
because code is still slowly evolving to take advantage of multi-core
architecture, and 64-bit memory, particularly for routing processes. The
headroom and performance on these has been phenomenal, and I can take
that to the bank.


Are you saying that the control plane experience lags behind general 
purpose computing?


Simply because you can afford the inflated pricing of the latest and 
greatest gear does not mean you should and it also does not mean the 
techniques available and in use to do so are in and of themselves 
suspect. No matter the temptation to do so.


To a certain extent, the market for the hardware probably accounts for 
and takes advantage of any such unwillingness to engineer around cost, 
whether it is due to pure design concerns or tinged with psychological 
suggestion.


Joe

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 25/Jan/16 12:15, Joe Maimon wrote:

>
>
> No static routes, dedicated BGP routed loopbacks on each side from an
> allocated /31, strict definitions on which routes belong to which
> session. Its gone about very properly.

And all of this is simpler than having a native BGP session that runs
across a point-to-point link?


>
> In my opinion, that setup is a very good example of how and when to
> properly take advantage of a BGP feature that has been with us from
> the start.

My philosophy: if I could run a router with only one command in its
configuration, I would.

I realize some commands make a router more secure than them being absent
(and vice versa), while some commands make a router perform better than
them being absent (and vice versa).

My point - just because a feature is there, does not mean you have to
use it.


>
> And really, whats wrong with the ability on your side to decide when
> and where on your network you will take a full feed of ever expanding
> internet routes. On your edge? On a purpose built route server?

Personally, I abhor tunnels (and things that resemble them) as well as
centralized networking. But that's just me.


>
> Or do you think the only paths forward for everyone's edges is
> continuous forklifting and/or selective filtering?

Can't speak for others, just myself.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Brandon Butterworth]

> From: Nick Hilliard 
> multihop bgp means that you don't have synchronised ethernet carrier
> status between the provider and customer routers.  This in turn means
> that if there's an intermediate connectivity problem, bgp will need to
> time out before it notices and reroutes.  During this period, traffic
> will be black-holed.  This is a crock.

It is but nobody worries about that, we trust route servers at IX
carrying way more traffic than most of these access circuits.

brandon

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 25/Jan/16 20:54, Scott Weeks wrote:

>
>
> Unless BFD is able to be used.
>
> https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection

Not many customers can support this.

And even if they did, not all implementations are executed in hardware
on either side of the BGP session.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 25/Jan/16 21:28, Brandon Butterworth wrote:

> It is but nobody worries about that, we trust route servers at IX
> carrying way more traffic than most of these access circuits.

Yes, but if those go belly-up, you have another exchange point to fall
back to, a bi-lateral peering session, or an upstream provider. Or all
three.

A "critical" device falling over in my network is far worse prospect to
experience.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Jared Mauch]

My understanding is this was mostly legacy from devices that did not carry full 
Rib and fib. There were tricks to avoid ending up on these skinny devices if 
you wanted. 

Life in the core has changed a lot in recent years from 6500/7600 and 
foundry/brocade class devices to a more interesting set in the pipeline or 
released. 

There are some limited rib-> fib download boxes that could slice traffic in 
cost effective ways that the price conscious consumer will likely push the 
market to. 

Jared Mauch

> On Jan 22, 2016, at 3:28 PM, Joe Maimon  wrote:
> 
> 
> I have a pending request to get that multi-hop setup. I was told that it was 
> now a special request and they would "try" to get it done and these days all 
> their routers had full table capacity and they no longer used the multi-hop.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 25/Jan/16 20:13, Joe Maimon wrote:

>
>
> Maybe not for some people, but I have a hard time understanding why
> one extra ebgp session is such a novel concept for all you networking
> folk.

It's not that novel - I share my view of the Internet with various
industry initiatives this way.

But for a commercial service, the decoupling between the state of the
physical link and the control plane in this case creates an opportunity
for various forwarding issues that are avoidable. The BFD argument could
be made, but it is not yet a basic feature one can expect with one's
customers.


>
>  
>
> They sell those routers at your nearest staples, they require zero
> commands.

No Staples this side of the world...


>
>
> I know you know better. What does this have to do with tunnels? Or how
> centralized your network is built or not?

Not everyone has the luxury of carrying a full table at the edge, for
various reasons, and I get that (even though in 2016, selective BGP FIB
downloads is a reality).

But if you can avoid it, determining one or two boxes in your core that
are your full BGP table reference puts a great deal of burden on those
devices to run and maintain routability for and within your network. If
I had the ability not to do this, I would, despite how sexy eBGP
Multi-Hop might be.

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Nick Hilliard]

Joe Maimon wrote:
> Maybe not for some people, but I have a hard time understanding why one
> extra ebgp session is such a novel concept for all you networking folk.

multihop bgp means that you don't have synchronised ethernet carrier
status between the provider and customer routers.  This in turn means
that if there's an intermediate connectivity problem, bgp will need to
time out before it notices and reroutes.  During this period, traffic
will be black-holed.  This is a crock.

Nick

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Joe Maimon]

Mark Tinka wrote:



On 25/Jan/16 12:15, Joe Maimon wrote:




No static routes, dedicated BGP routed loopbacks on each side from an
allocated /31, strict definitions on which routes belong to which
session. Its gone about very properly.


And all of this is simpler than having a native BGP session that runs
across a point-to-point link?


Maybe not for some people, but I have a hard time understanding why one 
extra ebgp session is such a novel concept for all you networking folk.




My philosophy: if I could run a router with only one command in its
configuration, I would.


They sell those routers at your nearest staples, they require zero commands.



Personally, I abhor tunnels (and things that resemble them) as well as
centralized networking. But that's just me.



I know you know better. What does this have to do with tunnels? Or how 
centralized your network is built or not?


Joe

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Scott Weeks]

--- n...@foobar.org wrote:
multihop bgp means that you don't have synchronised ethernet carrier
status between the provider and customer routers.  This in turn means
that if there's an intermediate connectivity problem, bgp will need to
time out before it notices and reroutes.  During this period, traffic
will be black-holed.  This is a crock.
---


Unless BFD is able to be used.

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

scott

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Nick Hilliard]

Brandon Butterworth wrote:
> It is but nobody worries about that, we trust route servers at IX
> carrying way more traffic than most of these access circuits.

more sessions for sure, but rarely more traffic.

The issue at hand is that multihop bgp at the isp edge is relatively
straightforward to fix by using big boxes, or mpls PW head-end to tunnel
to a big box, or by using small-fib boxes with large RIBs and selective
fib download.

IXPs solve a different set of problems, namely how to interconnect with
large numbers of third party organisations with low admin overhead.
There aren't easy solutions here.

Nick

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Joe Maimon]

Mark Tinka wrote:



On 25/Jan/16 20:13, Joe Maimon wrote:




Maybe not for some people, but I have a hard time understanding why
one extra ebgp session is such a novel concept for all you networking
folk.


It's not that novel - I share my view of the Internet with various
industry initiatives this way.


It appears that to route on the edge with multihop is viewed as novel.

And going further, multihop is quite novel to BGP Engineers in many a 
location, as per personal experience.




But for a commercial service, the decoupling between the state of the
physical link and the control plane in this case creates an opportunity
for various forwarding issues that are avoidable. The BFD argument could
be made, but it is not yet a basic feature one can expect with one's
customers.



Before BFD, we had keepalives right in BGP. Whats wrong with that?

I suppose you also advocate that each provider use a phy port directly 
on the ege, no switches in between, so that the full table can be yanked 
out as quickly as possible and that it be flooded back in as soon as 
possible, as many times as possible...








I know you know better. What does this have to do with tunnels? Or how
centralized your network is built or not?


Not everyone has the luxury of carrying a full table at the edge, for
various reasons, and I get that (even though in 2016, selective BGP FIB
downloads is a reality).


The question is whether it is a reality for gear that already cannot 
support full tables (likely EoS), or that is projected not to support 
them in the future. And which is practical to obtain and operate.


Further, FIB is one part. Collecting multiple full tables can also 
impose a dram burden on an edge router.


And churn on its CPU. Crypto, policy, etc.

Lets face it. An edge device control processor and memory is not the 
ideal location for all this. It does not compare with the GP hardware 
available for that task and it never will.





But if you can avoid it, determining one or two boxes in your core that
are your full BGP table reference puts a great deal of burden on those
devices to run and maintain routability for and within your network. If
I had the ability not to do this, I would, despite how sexy eBGP
Multi-Hop might be.

Mark.



Who says it must be that way? You could go the other extreme, it is 
quite feasible to have multiple RR's per pop (if thats what you want) 
and you can even segregate each eBGP feed into its own BGP router 
process, using a fraction of the hardware resources available to you in 
todays 1U server, available at a fraction of the cost of yesterday's edge.


It is not too hard to see that this approach offers a degree of design 
freedom that coupling your ebgp directly to your edge does not.


Joe

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Brandon Butterworth]

> From mark.ti...@seacom.mu  Mon Jan 25 19:56:46 2016
> > On 25/Jan/16 21:28, Brandon Butterworth wrote:
> > It is but nobody worries about that, we trust route servers at IX
> > carrying way more traffic than most of these access circuits.
> 
> Yes, but if those go belly-up, you have another exchange point to fall
> back to, a bi-lateral peering session, or an upstream provider. Or all
> three.

Doesn't matter, if traffic is blackholed at an ix then it
won't be failing over to another one. Same effect

> A "critical" device falling over in my network is far worse prospect to
> experience.

The general case doesn't care about your network, it assumes you'd
engineer that appropriately for the criticality and do something
different/better if you need to.

brandon

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Owen DeLong]

Actually, where I have mostly seen the biggest problems with the Cogent remote 
BGP
hacks is when their forwarding decisions in between your router and their BGP
speaking router don’t actually deliver your packets to the BGP speaking router
and your traffic starts veering wildly off course to god knows where.

Likely they’ve gotten better at avoiding this over the years, but there were 
times
when it resulted in very interesting loops and very strange paths that often
did not ever reach the intended destination.

Worse, when you encountered one of these hairballs, finding someone at AS174 
with
enough clue to understand your traceroutes let alone fix anything was an 
additional
challenge.

Owen

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mark Tinka]

On 22/Jan/16 22:28, Joe Maimon wrote:

>
>
> I like that setup. And it never struck me as crazy. In fact, their
> implementation avoids all multihop setup shortcuts and is quite purist
> from a routing standpoint.

First time I've heard that...

Mark.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Joe Maimon]

Mark Tinka wrote:



On 22/Jan/16 22:28, Joe Maimon wrote:




I like that setup. And it never struck me as crazy. In fact, their
implementation avoids all multihop setup shortcuts and is quite purist
from a routing standpoint.


First time I've heard that...

Mark.



No static routes, dedicated BGP routed loopbacks on each side from an 
allocated /31, strict definitions on which routes belong to which 
session. Its gone about very properly.


In my opinion, that setup is a very good example of how and when to 
properly take advantage of a BGP feature that has been with us from the 
start.


And really, whats wrong with the ability on your side to decide when and 
where on your network you will take a full feed of ever expanding 
internet routes. On your edge? On a purpose built route server?


Or do you think the only paths forward for everyone's edges is 
continuous forklifting and/or selective filtering?


I suspect that people are as much wary of the flexibility made available 
to them as they are to the "complexity" imposed via this approach.


Joe

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Tore Anderson]

William,

> Don't get me wrong. You can cure this fraud without going to extremes.
> An open peering policy doesn't require you to buy hardware for the
> other guy's convenience. Let him reimburse you or procure the hardware
> you spec out if he wants to peer. Nor do you have to extend your
> network to a location convenient for the other guy. Pick neutral
> locations where you're willing to peer and let the other guy build to
> them or pay you to build from there to him. Nor does an open peering
> policy require you to give the other guy a free ride on your
> international backbone: you can swap packets for just the regions of
> your network in which he's willing to establish a connection. But not
> ratios and traffic minimums -- those are not egalitarian, they're
> designed only to exclude the powerless.
> 
> Taken in this context, the Cogent/HE IPv6 peering spat is very simple:
> Cogent is -the- bad actor. 100%.

I'm curious: How do you know that Cogent didn't offer to peer under
terms such as the ones you mention, but that those were refused by HE?

Tore

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Doug Barton]

On 01/23/2016 02:43 AM, Tore Anderson wrote:

William,


Don't get me wrong. You can cure this fraud without going to extremes.
An open peering policy doesn't require you to buy hardware for the
other guy's convenience. Let him reimburse you or procure the hardware
you spec out if he wants to peer. Nor do you have to extend your
network to a location convenient for the other guy. Pick neutral
locations where you're willing to peer and let the other guy build to
them or pay you to build from there to him. Nor does an open peering
policy require you to give the other guy a free ride on your
international backbone: you can swap packets for just the regions of
your network in which he's willing to establish a connection. But not
ratios and traffic minimums -- those are not egalitarian, they're
designed only to exclude the powerless.

Taken in this context, the Cogent/HE IPv6 peering spat is very simple:
Cogent is -the- bad actor. 100%.


I'm curious: How do you know that Cogent didn't offer to peer under
terms such as the ones you mention, but that those were refused by HE?


Because Cogent has repeatedly stated that they refuse to peer, period?

Doug

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mike Hammett]

"I've said it before and I'll say it again: an ISP's refusal to 
maintain a settlement-free open peering policy is directly linked with 
said company's fraudulent double-billing for services." 


aaannnddd.. I'm done with that post. 




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



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


- Original Message -

From: "William Herrin"  
To: "Brandon Butterworth"  
Cc: nanog@nanog.org 
Sent: Friday, January 22, 2016 7:03:34 PM 
Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
Electric - and how to solve it 

On Thu, Jan 21, 2016 at 1:52 PM, Brandon Butterworth 
 wrote: 
> I'd like to peer with all tier 1's, they are thus all bad as 
> they won't. 

Correct. 

I've said it before and I'll say it again: an ISP's refusal to 
maintain a settlement-free open peering policy is directly linked with 
said company's fraudulent double-billing for services. 

In case you don't see it, I'll explain: whatever fictions you may tell 
yourselves, your customers pay you to connect them to the entire 
Internet. So do the other guy's customers. Settlement free peering 
means that at no _additional_ charge to anyone, you accept the packets 
your customers have paid you to accept from the other guy's customers. 
And vice versa. Peering does not trade packets you haven't been paid 
for. That's another fiction. Peering only trades packets one of your 
customers has paid you for. 

I get from there to double-billing because the alternative to 
settlement free peering is a paid relationship. The other guy has to 
buy from you directly (becoming the second payer for each packet) or 
he has to buy from one of the peers you've accepted But the peers 
you've accepted are constrained by ratios an related technical 
requirements which functionally prevent them from adding a sizable 
amount of traffic from that other guy, so unless he's doing a trifling 
business he pretty much has to buy service from you. Even though 
another customer has already paid you to perform that activity, you 
refuse to do the job unless the second party also becomes your 
customer and pays you. Fraud. Hidden behind a wall of technical 
minutiae but fraud all the same. 


Don't get me wrong. You can cure this fraud without going to extremes. 
An open peering policy doesn't require you to buy hardware for the 
other guy's convenience. Let him reimburse you or procure the hardware 
you spec out if he wants to peer. Nor do you have to extend your 
network to a location convenient for the other guy. Pick neutral 
locations where you're willing to peer and let the other guy build to 
them or pay you to build from there to him. Nor does an open peering 
policy require you to give the other guy a free ride on your 
international backbone: you can swap packets for just the regions of 
your network in which he's willing to establish a connection. But not 
ratios and traffic minimums -- those are not egalitarian, they're 
designed only to exclude the powerless. 

Taken in this context, the Cogent/HE IPv6 peering spat is very simple: 
Cogent is -the- bad actor. 100%. 

Regards, 
Bill Herrin 


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

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Joe Maimon]

Owen DeLong wrote:






Crazy multihop BGP setups


I like that setup. And it never struck me as crazy. In fact, their 
implementation avoids all multihop setup shortcuts and is quite purist 
from a routing standpoint.



The multihop approach gives you the option of where to slice and dice 
your full table direct from ebgp.


In essence, that setup enables you as a customer to have a setup exactly 
like Cogent had as a vendor. If thats what you want.



because they don’t do BGP on many (most?) of their customer facing routers?



I have a pending request to get that multi-hop setup. I was told that it 
was now a special request and they would "try" to get it done and these 
days all their routers had full table capacity and they no longer used 
the multi-hop.




Frequent outages in many locations (maybe not where you are, seems to be 
certain problem areas on their network and not others)
Spamtastic sales force?
Overly aggressive sales calls?

I’m sure there are more, but as I’ve never been a Cogent customer (thankfully) 
due to their history of bad peering policies, peering disputes, generally 
obnoxious conduct as a company, etc. it is difficult for me to know much about 
the customer experience beyond what I hear from others, most of whom are former 
Cogent customers.

Interestingly, when I worked for HE, I wasn’t allowed to speak my mind about 
Cogent lest it “reflect badly” on HE.

Owen

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Owen DeLong]

> On Jan 21, 2016, at 10:52 AM, Brandon Butterworth  
> wrote:
> 
>>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>>> wrote:
>>> Since Cogent is clearly the bad actor here (the burden being
>>> Cogent's to prove otherwise because HE is publicly on record as saying
>>> that theyd love to peer with Cogent)
> 
> I'd like to peer with all tier 1's, they are thus all bad as
> they won't.
> 
> HE decided they want to be transit free for v6 and set out on
> a campaign of providing free tunnels/transit/peering to establish
> this. Cogent, for all their faults, are free to not accept the
> offer.
> 
> Can the Cogent bashing stop now, save it for when they do something
> properly bad.
> 
> brandon

You are, of course, entitled to your opinion and I assure you that I am fully 
cognizant of
the fact that HE is not without its faults.

However, I think your description of the scenario is rather heavily skewed, 
especially
when you consider that Cogent is basically the only remaining major (I find it 
hard
to call them a tier 1 given their behavior) provider that still refuses SFI of 
any form
with HE.

Owen

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Owen DeLong]

> On Jan 21, 2016, at 10:47 AM, Robert Glover  wrote:
> 
> On 1/21/2016 10:40 AM, Daniel Corbe wrote:
>>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>>> wrote:
>>> 
>>> Since Cogent is clearly the bad actor here (the burden being Cogent's to 
>>> prove otherwise because HE is publicly on record as saying that they’d love 
>>> to peer with Cogent), I’m giving serious consideration to dropping Cogent 
>>> come renewal time and utilizing NTT or Zayo instead.
>>> 
>>> While that would not immediately solve the problem that if the NTT or Zayo 
>>> link went down, single-homed Cogent customers would loose access to me via 
>>> IPv6, I’m actually ok with that.  It at least lets ensures that when there 
>>> is a problem, the problem affects only single-home Cogent clients.  Thus, 
>>> the problem is borne exclusively by the people who pay the bad actor who is 
>>> causing this problem.  That tends to get uncomfortable for the payee (i.e. 
>>> Cogent).
>>> 
>>> 
>> Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent 
>> is probably banking on this being the response; figuring that they have the 
>> financial resources to outlast HE if they’re both shedding customers.
>> 
>> If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
>> two of any other providers besides Cogent.
>> 
>> Cogent clearly aren’t going to cave to their own customers asking them to 
>> peer with HE.  Otherwise it would have happened by now.
>> 
>> Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.
>> 
>> 
> Let's hear the top 5.   Peering disputes are up there, but what else?
> 
> We've had them as one of our providers going on 8 years, and we can only 
> complain about the occasional peering disputes.

Crazy multihop BGP setups because they don’t do BGP on many (most?) of their 
customer facing routers?
Frequent outages in many locations (maybe not where you are, seems to be 
certain problem areas on their network and not others)
Spamtastic sales force?
Overly aggressive sales calls?

I’m sure there are more, but as I’ve never been a Cogent customer (thankfully) 
due to their history of bad peering policies, peering disputes, generally 
obnoxious conduct as a company, etc. it is difficult for me to know much about 
the customer experience beyond what I hear from others, most of whom are former 
Cogent customers.

Interestingly, when I worked for HE, I wasn’t allowed to speak my mind about 
Cogent lest it “reflect badly” on HE.

Owen

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[jim deleskie]

Was part of my first peering spat, probably 95/96‎ since then many more,
couple even big enough they made nanog/ industry news, end of day they are
all the same. If you need to reach every where have more then one provider,
it's good practice anyway, a single cust or even a bunch of cust are NOT
going to influence peer decisions, so build your network so any 2 sides not
playing not, will not impact you cust's, so at least they don't have reason
to complain to you.

-jim

On Thu, Jan 21, 2016 at 11:42 PM, Matthew D. Hardeman  wrote:

> An excellent point.  Nobody would tolerate this in IPv4 land.  Those
> disputes tended to end in days and weeks (sometimes months), but not years.
>
> That said, as IPv6 is finally gaining traction, I suspect we’ll be seeing
> less tolerance for this behavior.
>
>
> > On Jan 21, 2016, at 8:30 PM, Matthew Kaufman  wrote:
> >
> >
> >
> >> On Jan 21, 2016, at 1:05 PM, Ca By  wrote:
> >>
> >> On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth <
> bran...@rd.bbc.co.uk>
> >> wrote:
> >>
> > On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
> >>> mharde...@ipifony.com> wrote:
> > Since Cogent is clearly the bad actor here (the burden being
> > Cogent's to prove otherwise because HE is publicly on record as
> saying
> > that theyd love to peer with Cogent)
> >>>
> >>> I'd like to peer with all tier 1's, they are thus all bad as
> >>> they won't.
> >>>
> >>> HE decided they want to be transit free for v6 and set out on
> >>> a campaign of providing free tunnels/transit/peering to establish
> >>> this. Cogent, for all their faults, are free to not accept the
> >>> offer.
> >>>
> >>> Can the Cogent bashing stop now, save it for when they do something
> >>> properly bad.
> >>>
> >>> brandon
> >>
> >> Selling a service that is considered internet but does not deliver full
> >> internet access is generally considered properly bad.
> >>
> >> I would not do business with either company, since neither of them
> provide
> >> a full view.
> >>
> >> CB
> >
> > I note that if IPv6 was actually important, neither one could have
> gotten away with it for so long.
> >
> > Matthew Kaufman
> >
> > (Sent from my iPhone)
>
>

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Brandon Butterworth]

> From o...@delong.com  Fri Jan 22 10:25:26 2016
> However, I think your description of the scenario is rather
> heavily skewed

Most posts are bashing Cogent so it's bad of me to say they are equally
free to do whatever they want with their network? Mob rule...

I favour neither side. Nobody has to buy from either of them.

> especially when you consider that Cogent is basically the only
> remaining major (I find it hard to call them a tier 1 given
> their behavior) provider that still refuses SFI of any form
> with HE.

tier 1 seems consistent with Cogents refusal.

brandon

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Mike Hammett]

Motivated sales departments always get whatever they want. Always. If they 
aren't getting what they (or you as customer) want, they aren't motivated 
enough. 




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



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


- Original Message -

From: "jim deleskie"  
To: "Matthew D. Hardeman"  
Cc: nanog@nanog.org 
Sent: Friday, January 22, 2016 6:03:17 AM 
Subject: Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane 
Electric - and how to solve it 

Was part of my first peering spat, probably 95/96‎ since then many more, 
couple even big enough they made nanog/ industry news, end of day they are 
all the same. If you need to reach every where have more then one provider, 
it's good practice anyway, a single cust or even a bunch of cust are NOT 
going to influence peer decisions, so build your network so any 2 sides not 
playing not, will not impact you cust's, so at least they don't have reason 
to complain to you. 

-jim 

On Thu, Jan 21, 2016 at 11:42 PM, Matthew D. Hardeman  wrote: 

> An excellent point. Nobody would tolerate this in IPv4 land. Those 
> disputes tended to end in days and weeks (sometimes months), but not years. 
> 
> That said, as IPv6 is finally gaining traction, I suspect we’ll be seeing 
> less tolerance for this behavior. 
> 
> 
> > On Jan 21, 2016, at 8:30 PM, Matthew Kaufman  wrote: 
> > 
> > 
> > 
> >> On Jan 21, 2016, at 1:05 PM, Ca By  wrote: 
> >> 
> >> On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth < 
> bran...@rd.bbc.co.uk> 
> >> wrote: 
> >> 
> > On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman < 
> >>> mharde...@ipifony.com> wrote: 
> > Since Cogent is clearly the bad actor here (the burden being 
> > Cogent's to prove otherwise because HE is publicly on record as 
> saying 
> > that theyd love to peer with Cogent) 
> >>> 
> >>> I'd like to peer with all tier 1's, they are thus all bad as 
> >>> they won't. 
> >>> 
> >>> HE decided they want to be transit free for v6 and set out on 
> >>> a campaign of providing free tunnels/transit/peering to establish 
> >>> this. Cogent, for all their faults, are free to not accept the 
> >>> offer. 
> >>> 
> >>> Can the Cogent bashing stop now, save it for when they do something 
> >>> properly bad. 
> >>> 
> >>> brandon 
> >> 
> >> Selling a service that is considered internet but does not deliver full 
> >> internet access is generally considered properly bad. 
> >> 
> >> I would not do business with either company, since neither of them 
> provide 
> >> a full view. 
> >> 
> >> CB 
> > 
> > I note that if IPv6 was actually important, neither one could have 
> gotten away with it for so long. 
> > 
> > Matthew Kaufman 
> > 
> > (Sent from my iPhone) 
> 
> 

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Constantine A. Murenin]

On 21 January 2016 at 19:42, Matthew D. Hardeman  wrote:
> An excellent point.  Nobody would tolerate this in IPv4 land.  Those disputes 
> tended to end in days and weeks (sometimes months), but not years.
>
> That said, as IPv6 is finally gaining traction, I suspect we’ll be seeing 
> less tolerance for this behavior.

Nope.  Most user-facing apps are in support of Happy Eyeballs.

When Facebook's FB.ME was down on IPv6 just a short while ago in 2013,
it took DAYS for anyone to notice.

  http://puck.nether.net/pipermail/outages/2013-May/005571.html

Lots of popular sites publish  with non-reachable services all the
time, and still noone notices to this day.

The old school command line tools are the only ones affected.  One may
also notice it with `ssh -D` SOCKS5 proxying, but only if one's
browser doesn't decide to leak out hostname resolution and operate
directly with IPv4-addresses to start with, like Chrome does.

Cheers,
Constantine.SU.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

While I agree it’s still going to be a while before it becomes a critical 
issue, more and more environments are going IPv6 first with IPv4 as a NAT’ed 
service…

I think the mobile carriers are going to be the ones to really push adoption.

> On Jan 22, 2016, at 7:53 PM, Constantine A. Murenin  
> wrote:
> 
> On 21 January 2016 at 19:42, Matthew D. Hardeman  
> wrote:
>> An excellent point.  Nobody would tolerate this in IPv4 land.  Those 
>> disputes tended to end in days and weeks (sometimes months), but not years.
>> 
>> That said, as IPv6 is finally gaining traction, I suspect we’ll be seeing 
>> less tolerance for this behavior.
> 
> Nope.  Most user-facing apps are in support of Happy Eyeballs.
> 
> When Facebook's FB.ME was down on IPv6 just a short while ago in 2013,
> it took DAYS for anyone to notice.
> 
>  http://puck.nether.net/pipermail/outages/2013-May/005571.html
> 
> Lots of popular sites publish  with non-reachable services all the
> time, and still noone notices to this day.
> 
> The old school command line tools are the only ones affected.  One may
> also notice it with `ssh -D` SOCKS5 proxying, but only if one's
> browser doesn't decide to leak out hostname resolution and operate
> directly with IPv4-addresses to start with, like Chrome does.
> 
> Cheers,
> Constantine.SU.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[William Herrin]

On Thu, Jan 21, 2016 at 1:52 PM, Brandon Butterworth
 wrote:
> I'd like to peer with all tier 1's, they are thus all bad as
> they won't.

Correct.

I've said it before and I'll say it again: an ISP's refusal to
maintain a settlement-free open peering policy is directly linked with
said company's fraudulent double-billing for services.

In case you don't see it, I'll explain: whatever fictions you may tell
yourselves, your customers pay you to connect them to the entire
Internet. So do the other guy's customers. Settlement free peering
means that at no _additional_ charge to anyone, you accept the packets
your customers have paid you to accept from the other guy's customers.
And vice versa. Peering does not trade packets you haven't been paid
for. That's another fiction. Peering only trades packets one of your
customers has paid you for.

I get from there to double-billing because the alternative to
settlement free peering is a paid relationship. The other guy has to
buy from you directly (becoming the second payer for each packet) or
he has to buy from one of the peers you've accepted But the peers
you've accepted are constrained by ratios an related technical
requirements which functionally prevent them from adding a sizable
amount of traffic from that other guy, so unless he's doing a trifling
business he pretty much has to buy service from you. Even though
another customer has already paid you to perform that activity, you
refuse to do the job unless the second party also becomes your
customer and pays you. Fraud. Hidden behind a wall of technical
minutiae but fraud all the same.


Don't get me wrong. You can cure this fraud without going to extremes.
An open peering policy doesn't require you to buy hardware for the
other guy's convenience. Let him reimburse you or procure the hardware
you spec out if he wants to peer. Nor do you have to extend your
network to a location convenient for the other guy. Pick neutral
locations where you're willing to peer and let the other guy build to
them or pay you to build from there to him. Nor does an open peering
policy require you to give the other guy a free ride on your
international backbone: you can swap packets for just the regions of
your network in which he's willing to establish a connection. But not
ratios and traffic minimums -- those are not egalitarian, they're
designed only to exclude the powerless.

Taken in this context, the Cogent/HE IPv6 peering spat is very simple:
Cogent is -the- bad actor. 100%.

Regards,
Bill Herrin


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

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

Bill,

I find that I agree with much of what you’ve said.

If we further constrain the arguments that you set forth so as to cover only 
that traffic which the customers of the two networks would be able to exchange 
in any event, by way of transit services purchased by one or the other of the 
two networks, then I agree wholeheartedly, at least on a purely logical basis.

In that instance, the traffic is exchanged regardless (though often over links 
that saturate at peaks) and furthermore at additional expense to one or both of 
the networks involved.

From a logical perspective, if two networks will permit their subscribers to 
exchange data, why would those two networks not elect the least cost, highest 
quality mechanism for exchanging that traffic?

I can only think of economic reasons, and specifically the hope for potential 
revenue from the other networks’ customer, because the parties have been unable 
to exchange data reliably over congested transit links.

Look, for example, to what was quite obviously the intentional peak-period 
congestion on various Comcast transit and peering links.

I’ve personally acted in a technical and administrative capacity in helping 
clients of mine (voice service providers) add private paid peering / paid 
customer links into Comcast just to overcome voice quality issues during peak 
periods resulting from clearly congested transit and peering links.  It was 
obvious during those arrangements that Comcast had chosen to allow those links 
to congest as a policy matter in order to extract additional revenue by 
charging desperate “new customers” a premium toll for access to their 
subscribers behind the wall-of-congestion.

What’s fundamentally different in this IPv6 only Hurricane Electric <-> Cogent 
matter is that rather than have the traffic flow via transit (whether congested 
or not), there is quite simply no path between those two IPv6 networks.  
Hurricane Electric, clearly the IPv6 leader refuses to engage in the purchase 
of transit services for IPv6, and Cogent refuses to peer with HE on either 
protocol no matter what.  Thus, no flow of traffic between the two networks on 
IPv6.

Presumably Cogent’s policy is mostly about denying Hurricane Electric to the 
“Tier 1” club, on IPv6 that ship has sailed.  Let’s face it: when the really 
tough Tier 1s are peering with you (like Sprint, Level 3, AT), you’re in.  
Even Sprint peers with HE on IPv6 (though they do not on IPv4).  Honestly, I 
think Cogent is the only hold-out.  At least the only one that matters.

In as far as HE maintains an open peering policy both for IPv4 and IPv6, it’s 
clear that Cogent is the bad actor, denying their customers a path to Hurricane 
Electric customers.  I think the only reason this has been tolerated so far is 
that IPv6 has been a fringe matter until now.  Even today it’s a minority of 
network traffic, but it’s gaining fast.

If I were Cogent, I’d be more worried about denying my customers access to HE’s 
IPv6 network than the other way around.

Matt Hardeman


> On Jan 22, 2016, at 7:03 PM, William Herrin  wrote:
> 
> On Thu, Jan 21, 2016 at 1:52 PM, Brandon Butterworth
>  wrote:
>> I'd like to peer with all tier 1's, they are thus all bad as
>> they won't.
> 
> Correct.
> 
> I've said it before and I'll say it again: an ISP's refusal to
> maintain a settlement-free open peering policy is directly linked with
> said company's fraudulent double-billing for services.
> 
> In case you don't see it, I'll explain: whatever fictions you may tell
> yourselves, your customers pay you to connect them to the entire
> Internet. So do the other guy's customers. Settlement free peering
> means that at no _additional_ charge to anyone, you accept the packets
> your customers have paid you to accept from the other guy's customers.
> And vice versa. Peering does not trade packets you haven't been paid
> for. That's another fiction. Peering only trades packets one of your
> customers has paid you for.
> 
> I get from there to double-billing because the alternative to
> settlement free peering is a paid relationship. The other guy has to
> buy from you directly (becoming the second payer for each packet) or
> he has to buy from one of the peers you've accepted But the peers
> you've accepted are constrained by ratios an related technical
> requirements which functionally prevent them from adding a sizable
> amount of traffic from that other guy, so unless he's doing a trifling
> business he pretty much has to buy service from you. Even though
> another customer has already paid you to perform that activity, you
> refuse to do the job unless the second party also becomes your
> customer and pays you. Fraud. Hidden behind a wall of technical
> minutiae but fraud all the same.
> 
> 
> Don't get me wrong. You can cure this fraud without going to extremes.
> An open peering policy doesn't require you to buy hardware for the
> other guy's convenience. Let 

The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

Hi everyone,

I know the long and storied history of Cogent and HE failing to peer for IPv6 
and failing to provide (from either side) for IPv6 transit between their two 
networks has been mentioned and covered on this list before, but I am rather 
surprised it has not garnered much attention.

Until recently, that is.  I notice an increasing number of people tweeting at 
both HE and Cogent about the problem.

From HE’s public statements on the matter, it’s pretty clear that they would 
gladly peer with Cogent for IPv6 but that Cogent declines to do this.  I simply 
cannot understand Cogent’s logic on this.  Cogent is the one loosing out here, 
to my way of thinking.  They have far less IPv6 coverage than HE.

I myself, on behalf of my employers, am a direct customer of IP transit 
services from both Cogent and HE.

I don’t know about others similarly positioned, but my Cogent rep tries to call 
me at least twice a month.  I’m going to start taking (more of) his calls and 
letting him know his account with us is in jeopardy come renewal time if Cogent 
can’t get a full IPv6 route table to happen.

Today, with Cogent & HE as peers, I am world reachable via IPv6.  If either 
peer went down however, part of the internet couldn’t reach me via IPv6 because 
either HE wouldn’t have a route or Cogent wouldn’t have a route.  That’s 
ridiculous.

Since Cogent is clearly the bad actor here (the burden being Cogent's to prove 
otherwise because HE is publicly on record as saying that they’d love to peer 
with Cogent), I’m giving serious consideration to dropping Cogent come renewal 
time and utilizing NTT or Zayo instead.

While that would not immediately solve the problem that if the NTT or Zayo link 
went down, single-homed Cogent customers would loose access to me via IPv6, I’m 
actually ok with that.  It at least lets ensures that when there is a problem, 
the problem affects only single-home Cogent clients.  Thus, the problem is 
borne exclusively by the people who pay the bad actor who is causing this 
problem.  That tends to get uncomfortable for the payee (i.e. Cogent).

I intend to email my Cogent sales guy regarding this matter and make this a 
sticking point in every phone conversation I have with him.  I call on others 
similarly situated to consider whether you may like to follow suit in this 
approach.  I’ve come to believe that it’s best for my interests and I also 
believe that it’s best for the internet community at large, as ubiquitous 
worldwide routing of IPv6 becomes more essential with each passing day.

In closing, I further add that it’s a mystery to me why Cogent wouldn’t desire 
an IPv6 peering with HE.  Let’s face it, if any of us had to choose a 
single-home IPv6 internet experience, between HE or Cogent, we’d all choose HE. 
 If those were the two options, HE is the “real” IPv6 internet and Cogent is a 
tiny sliver of the IPv6 internet.  I have actually wondered if HE is holding 
IPv6 peering with Cogent hostage, contingent on peering all protocols (IPv4 and 
IPv6) with Cogent.  There, I could see why Cogent might hesitate.  To my 
knowledge, however, this is not the case and I have heard no public accusation 
that HE is imposing such a constraint.  I would love to hear anyone from HE 
tell as much of the story as they are able.

PS - As an aside, has anyone noticed HE’s been growing their network by leaps 
and bounds this past year?  Direct peerings with AT and CenturyLink, more 
domestic US and Canadian POPs, and I believe the number of pathways across the 
North American continent has been improved substantially, too.

Thanks,

Matt Hardeman
IPiFony Systems, Inc.
AS6082

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

I’m inclined to agree with you, subject to some caveats:

1.  I think more Cogent customers need to be more vocal about it.  There hasn’t 
been an impetus to do so until recently.  Now real people (not network engineer 
sorts) are starting to use IPv6 for real.

2.  I agree with you in principle.  In an idea world, take HE and two others.  
I would however still say that if you could only take two, take HE and take 
something other than Cogent.  It’s a win-win if the experience of single-home 
Cogent customers gets to be worse as a result.  Perhaps having things 
occasionally break — only for single-home Cogent customers — is a benefit.


> On Jan 21, 2016, at 12:40 PM, Daniel Corbe  wrote:
> 
> 
>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>> wrote:
>> 
>> Since Cogent is clearly the bad actor here (the burden being Cogent's to 
>> prove otherwise because HE is publicly on record as saying that they’d love 
>> to peer with Cogent), I’m giving serious consideration to dropping Cogent 
>> come renewal time and utilizing NTT or Zayo instead.
>> 
>> While that would not immediately solve the problem that if the NTT or Zayo 
>> link went down, single-homed Cogent customers would loose access to me via 
>> IPv6, I’m actually ok with that.  It at least lets ensures that when there 
>> is a problem, the problem affects only single-home Cogent clients.  Thus, 
>> the problem is borne exclusively by the people who pay the bad actor who is 
>> causing this problem.  That tends to get uncomfortable for the payee (i.e. 
>> Cogent).
>> 
>> 
> 
> Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent 
> is probably banking on this being the response; figuring that they have the 
> financial resources to outlast HE if they’re both shedding customers.  
> 
> If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
> two of any other providers besides Cogent.  
> 
> Cogent clearly aren’t going to cave to their own customers asking them to 
> peer with HE.  Otherwise it would have happened by now.  
> 
> Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.
> 
> 

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Daniel Corbe]

> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
> wrote:
> 
> Since Cogent is clearly the bad actor here (the burden being Cogent's to 
> prove otherwise because HE is publicly on record as saying that they’d love 
> to peer with Cogent), I’m giving serious consideration to dropping Cogent 
> come renewal time and utilizing NTT or Zayo instead.
> 
> While that would not immediately solve the problem that if the NTT or Zayo 
> link went down, single-homed Cogent customers would loose access to me via 
> IPv6, I’m actually ok with that.  It at least lets ensures that when there is 
> a problem, the problem affects only single-home Cogent clients.  Thus, the 
> problem is borne exclusively by the people who pay the bad actor who is 
> causing this problem.  That tends to get uncomfortable for the payee (i.e. 
> Cogent).
> 
> 

Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent is 
probably banking on this being the response; figuring that they have the 
financial resources to outlast HE if they’re both shedding customers.  

If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
two of any other providers besides Cogent.  

Cogent clearly aren’t going to cave to their own customers asking them to peer 
with HE.  Otherwise it would have happened by now.  

Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Brandon Butterworth]

> > On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
> > wrote:
> > Since Cogent is clearly the bad actor here (the burden being
> > Cogent's to prove otherwise because HE is publicly on record as saying
> > that theyd love to peer with Cogent)

I'd like to peer with all tier 1's, they are thus all bad as
they won't.

HE decided they want to be transit free for v6 and set out on
a campaign of providing free tunnels/transit/peering to establish
this. Cogent, for all their faults, are free to not accept the
offer.

Can the Cogent bashing stop now, save it for when they do something
properly bad.

brandon

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Robert Glover]

On 1/21/2016 10:40 AM, Daniel Corbe wrote:

On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  wrote:

Since Cogent is clearly the bad actor here (the burden being Cogent's to prove 
otherwise because HE is publicly on record as saying that they’d love to peer 
with Cogent), I’m giving serious consideration to dropping Cogent come renewal 
time and utilizing NTT or Zayo instead.

While that would not immediately solve the problem that if the NTT or Zayo link 
went down, single-homed Cogent customers would loose access to me via IPv6, I’m 
actually ok with that.  It at least lets ensures that when there is a problem, 
the problem affects only single-home Cogent clients.  Thus, the problem is 
borne exclusively by the people who pay the bad actor who is causing this 
problem.  That tends to get uncomfortable for the payee (i.e. Cogent).



Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent is 
probably banking on this being the response; figuring that they have the 
financial resources to outlast HE if they’re both shedding customers.

If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
two of any other providers besides Cogent.

Cogent clearly aren’t going to cave to their own customers asking them to peer 
with HE.  Otherwise it would have happened by now.

Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.



Let's hear the top 5.   Peering disputes are up there, but what else?

We've had them as one of our providers going on 8 years, and we can only 
complain about the occasional peering disputes.


-Robert

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Ca By]

On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth 
wrote:

> > > On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
> mharde...@ipifony.com> wrote:
> > > Since Cogent is clearly the bad actor here (the burden being
> > > Cogent's to prove otherwise because HE is publicly on record as saying
> > > that theyd love to peer with Cogent)
>
> I'd like to peer with all tier 1's, they are thus all bad as
> they won't.
>
> HE decided they want to be transit free for v6 and set out on
> a campaign of providing free tunnels/transit/peering to establish
> this. Cogent, for all their faults, are free to not accept the
> offer.
>
> Can the Cogent bashing stop now, save it for when they do something
> properly bad.
>
> brandon
>

Selling a service that is considered internet but does not deliver full
internet access is generally considered properly bad.

I would not do business with either company, since neither of them provide
a full view.

CB

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Jack Bates]

On 1/21/2016 12:44 PM, Matthew D. Hardeman wrote:

I’m inclined to agree with you, subject to some caveats:

1.  I think more Cogent customers need to be more vocal about it.  There hasn’t 
been an impetus to do so until recently.  Now real people (not network engineer 
sorts) are starting to use IPv6 for real.

2.  I agree with you in principle.  In an idea world, take HE and two others.  
I would however still say that if you could only take two, take HE and take 
something other than Cogent.  It’s a win-win if the experience of single-home 
Cogent customers gets to be worse as a result.  Perhaps having things 
occasionally break — only for single-home Cogent customers — is a benefit.

Honestly, don't take HE or Cogent if you can help it. Neither deserves 
to be rewarded in this dispute. That being said, there are plenty of 
small customers that are single homed to both. Unfortunately, I doubt 
their voices matter.


Jack

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Daniel Corbe]

> On Jan 21, 2016, at 1:47 PM, Robert Glover  wrote:
> 
> On 1/21/2016 10:40 AM, Daniel Corbe wrote:
>>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>>> wrote:
>>> 
>>> Since Cogent is clearly the bad actor here (the burden being Cogent's to 
>>> prove otherwise because HE is publicly on record as saying that they’d love 
>>> to peer with Cogent), I’m giving serious consideration to dropping Cogent 
>>> come renewal time and utilizing NTT or Zayo instead.
>>> 
>>> While that would not immediately solve the problem that if the NTT or Zayo 
>>> link went down, single-homed Cogent customers would loose access to me via 
>>> IPv6, I’m actually ok with that.  It at least lets ensures that when there 
>>> is a problem, the problem affects only single-home Cogent clients.  Thus, 
>>> the problem is borne exclusively by the people who pay the bad actor who is 
>>> causing this problem.  That tends to get uncomfortable for the payee (i.e. 
>>> Cogent).
>>> 
>>> 
>> Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent 
>> is probably banking on this being the response; figuring that they have the 
>> financial resources to outlast HE if they’re both shedding customers.
>> 
>> If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
>> two of any other providers besides Cogent.
>> 
>> Cogent clearly aren’t going to cave to their own customers asking them to 
>> peer with HE.  Otherwise it would have happened by now.
>> 
>> Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.
>> 
>> 
> Let's hear the top 5.   Peering disputes are up there, but what else?
> 
> We've had them as one of our providers going on 8 years, and we can only 
> complain about the occasional peering disputes.
> 
> -Robert
> 

I don’t really have 5 reasons to hate cogent but I’ve got 3 big ones.  If 
you’ve had static transit with Cogent for 8 years at one or just a handful of 
locations, none of these will apply.  But..

1) They charge per IPv4 BGP session per month
2) They constantly screw up our orders.  
3) It then takes days for them to fix their own screw ups in their order 
system. 
 

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew Kaufman]

> On Jan 21, 2016, at 1:05 PM, Ca By  wrote:
> 
> On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth 
> wrote:
> 
 On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
>> mharde...@ipifony.com> wrote:
 Since Cogent is clearly the bad actor here (the burden being
 Cogent's to prove otherwise because HE is publicly on record as saying
 that theyd love to peer with Cogent)
>> 
>> I'd like to peer with all tier 1's, they are thus all bad as
>> they won't.
>> 
>> HE decided they want to be transit free for v6 and set out on
>> a campaign of providing free tunnels/transit/peering to establish
>> this. Cogent, for all their faults, are free to not accept the
>> offer.
>> 
>> Can the Cogent bashing stop now, save it for when they do something
>> properly bad.
>> 
>> brandon
> 
> Selling a service that is considered internet but does not deliver full
> internet access is generally considered properly bad.
> 
> I would not do business with either company, since neither of them provide
> a full view.
> 
> CB

I note that if IPv6 was actually important, neither one could have gotten away 
with it for so long.

Matthew Kaufman

(Sent from my iPhone)

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Randy Bush]

welcome to the commercial internet.  get over it.

randy

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

An excellent point.  Nobody would tolerate this in IPv4 land.  Those disputes 
tended to end in days and weeks (sometimes months), but not years.

That said, as IPv6 is finally gaining traction, I suspect we’ll be seeing less 
tolerance for this behavior.


> On Jan 21, 2016, at 8:30 PM, Matthew Kaufman  wrote:
> 
> 
> 
>> On Jan 21, 2016, at 1:05 PM, Ca By  wrote:
>> 
>> On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth 
>> wrote:
>> 
> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
>>> mharde...@ipifony.com> wrote:
> Since Cogent is clearly the bad actor here (the burden being
> Cogent's to prove otherwise because HE is publicly on record as saying
> that theyd love to peer with Cogent)
>>> 
>>> I'd like to peer with all tier 1's, they are thus all bad as
>>> they won't.
>>> 
>>> HE decided they want to be transit free for v6 and set out on
>>> a campaign of providing free tunnels/transit/peering to establish
>>> this. Cogent, for all their faults, are free to not accept the
>>> offer.
>>> 
>>> Can the Cogent bashing stop now, save it for when they do something
>>> properly bad.
>>> 
>>> brandon
>> 
>> Selling a service that is considered internet but does not deliver full
>> internet access is generally considered properly bad.
>> 
>> I would not do business with either company, since neither of them provide
>> a full view.
>> 
>> CB
> 
> I note that if IPv6 was actually important, neither one could have gotten 
> away with it for so long.
> 
> Matthew Kaufman
> 
> (Sent from my iPhone)



smime.p7s
Description: S/MIME cryptographic signature

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Tore Anderson]

* Ca By 

> Selling a service that is considered internet but does not deliver
> full internet access is generally considered properly bad.
> 
> I would not do business with either company, since neither of them
> provide a full view.

+1

Both networks are in a position to easily remedy the situation if they
were pragmatically inclined. For example, Cogent could simply accept
HE's offer to peer; HE could simply pick up Cogent's IPv6 routes from
their existing transit provider TSIC.

Instead they both choose to continue their game of chicken to the
detriment of both of their customer bases.

Fortunately there's no shortage of competitors to HE and Cogent who
prioritise providing connectivity higher than engaging in such
nonsense. Vote with your wallets, folks.

Tore

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

I hear you.

Taken to extremes, I can see how the argument sounds like that.

However…  I have some thoughts on what you’ve said.

Most of us would never get peerings to all the Tier 1s.

But…

Hurricane Electric already has IPv6 peering to every network that matters, save 
for Cogent’s.  Every other accepted Tier 1 peers with HE on IPv6.  Even SPRINT. 
 If we got back historically, they (Sprint) were among the most coveted and 
hardest to get IP peerings.  Even they recognized HE’s dominance of the IPv6 
space early on.

I’m not bashing Cogent.  I’m a customer of theirs and they’ve generally served 
me well.  The trouble I have in accepting Cogent’s behavior in this matter is 
that it just seems irrational.  If a typical, public forum peering dispute 
arose between HE & Cogent regarding IPv6, frankly and pretty objectively, you’d 
expect it to be Hurricane Electric questioning the value of peering Cogent IPv6 
rather than Cogent questioning HE.

I don’t question these parties’ rights not to peer, but I do question the logic 
behind it.  I think Cogent is hurting themselves on this more than HE is 
getting hurt by it.


> On Jan 21, 2016, at 12:52 PM, Brandon Butterworth  
> wrote:
> 
>>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>>> wrote:
>>> Since Cogent is clearly the bad actor here (the burden being
>>> Cogent's to prove otherwise because HE is publicly on record as saying
>>> that theyd love to peer with Cogent)
> 
> I'd like to peer with all tier 1's, they are thus all bad as
> they won't.
> 
> HE decided they want to be transit free for v6 and set out on
> a campaign of providing free tunnels/transit/peering to establish
> this. Cogent, for all their faults, are free to not accept the
> offer.
> 
> Can the Cogent bashing stop now, save it for when they do something
> properly bad.
> 
> brandon