Cogent-TATA peering dispute?

Mailman List Mirror (Read Only)
1

It would appear that ( as of yesterday ) some but not all BGP routes
between Cogent and TATA are gone.

India are now not visible from cogent connections/customers.

There's also a report of a cogent support ticket response from reddit
(so a small dump truck of salt might be warranted) that suggests it’s
a cogent instigated depeering (
https://www.reddit.com/r/networking/comments/1cu13bv/cogent_depeering_tata/
)

Dear customer,
For many years, Cogent has been trying to work with TATA on ensuring sufficient connectivity in each global region the networks operate per normal peering practices. Despite Cogent’s repeated requests, TATA has consistently refused to establish connectivity in Asia, taking advantage of Cogent’s good faith efforts while also ensuring sub-standard service to both companies customers. No amount of good will and good faith augments on Cogent’s part has brought TATA any closer to the negotiating table for a resolution to the lack of connectivity in Asia. This one-sided situation has become untenable and as a result, Cogent has elected to start the process of restricting connectivity to TATA.

From bgp.tools point of view, It seems that TATA has routes to cogent
in some places, but cogent does not have all TATA India/APAC routes.
Also poking around on RIPE Atlas suggests that for a non-zero amount
of networks in India the C DNS Root Server that cogent runs is
inaccessible: RIPE Atlas - RIPE Network Coordination Centre

Assuming these assumptions are true, there should be around 930
Cogent-Only ASNs and 645 TATA-Only ASNs who now have questionable
reachability to each other.

My (bgp.tools) visibility for TATA has always been quite slim,
especially in APAC, what do other people see on their TATA sessions?

2

I don't understand why Cogent is allowed to operate one of the root
servers. Doesn't ICANN do any kind of technical background check on
companies when letting the contract?

For those who haven't been around long enough, this isn't Cogent's
first depeering argument. Nor their second. And they're behaving
unreasonably. I don't know any of the details -this time- but
historically speaking Cogent is behaving badly -again- and you can
take that to the bank.

Regards,
Bill Herrin

3

Not even the first time tata and cogent separated. Will avoid public details but I was on the keyboard at 6453 that time.

4

It appears that William Herrin <bill@herrin.us> said:

I don't understand why Cogent is allowed to operate one of the root
servers. Doesn't ICANN do any kind of technical background check on
companies when letting the contract?

You must be new here. There is no contract for running root servers
and never has been.

We can all have our own opinions about the various operators.

R's,
John

5

I stand corrected. DNS root server FAQ | Netnod

Some of them have MoU's with ICANN (a contract with loosely defined
requirements) but apparently not all and it wasn't at ICANN's
discretion.

That said, ICANN generates the root zone including the servers
declared authoritative for the zone. So they do have an ability to
say: nope, you've crossed the line to any of the root operators.

So Cogent operates a root server because they bought PSI who ran a
root server and ICANN has never chosen to throw down the gauntlet.
Which is a fair answer to why they're allowed to operate one of the
roots.

Regards,
Bill Herrin

6

That said, ICANN generates the root zone including the servers
declared authoritative for the zone.

Nope.

So they do have an ability to
say: nope, you've crossed the line to any of the root operators.

Very very nope.

ICANN as the IANA Functions Operator maintains the database of TLD info. They provide this to Verisign, the Root Zone Maintainer, who create the root zone and distribute it to the root server operators. Verisign does this under a contract with NTIA, one of the few bits of the Internet that is still under a US government contract:

Should ICANN attempt to mess with the distribution of the root zone, let us just say that the results would not be pretty. There's a balance of terror here. ICANN carefully never does anything that would make the root server operators say no, and the root server operators carefully avoid putting ICANN in a position where they might have to do that.

I'm not guessing here, I go to ICANN meetings and talk to these people.

R's,
John

7

Cogent has been trying to establish themselves as a "tier 1" carrier in markets outside their home turf, and Asia is one of the markets in which the established operators are doing their best to keep Cogent out.

Back when I was helping to run a global anycast CDN, Cogent was one of our transits [in US and EU POPs]. I identified a bunch of sub-optimal service to networks in Asia who were silly/cheap enough to buy transit from Cogent. Since none of the established players would peer in-market with Cogent, and since we didn't have Cogent transit in any of our Asian POPs (why would we?), anycast request traffic from those Cogent customers would cross the Pacific and land in California rather than hit a nearby POP with NTT, Tata, Singtel, etc. transits.

I suspect Cogent has either reached what they consider to be customer critical mass in Asia, or is tired of their Asian customers complaining about latency (since traffic to any other in-market non-Cogent connected network routes via the US or EU) and has decided it's time to play peering chicken to force Tata to peer with them in Asia. Why shouldn't they? The only reason Tata, NTT, etc. won't peer with Cogent in-market is because they don't want Cogent to be able to compete with them in their home market.

8

Perhaps Cogent is permitted to operate a root server's infrastructure as an on-going, real-time disaster scenario - demonstrating what happens to critical DNS infrastructure when there's considerable routing loss.

Not much, it seems.

-joe

9

John is exactly correct on each of these points. And I guess I’d go a little further and say that ICANN and IANA are separate entities, with IANA predating ICANN by a decade.

                                -Bill

10

As John said, ICANN has nothing to do with who runs root servers. Last I knew, NTIA still believed that NTIA selects the root server operators. Eventually the last person at NTIA who still knows what that means will retire, and then nobody in the USG will believe that they have responsibility. Then, ICANN lawyers will presumably start insinuating that, actually, ICANN can do what it wants there. Which they’ve already laid the groundwork for by failing to reassign the L-root nameserver for the last twenty-two years. Not a task that should take twenty-two years, in my opinion… CGI is perfectly capable, and there are no root servers administered in the southern hemisphere. State and Commerce were considering reassigning it as an apology for the Rousseff spying incident in 2013, but they didn’t quite get it together to act.

                                -Bill

11

They’re also still in the middle of one with NTT.

                                -Bill

12

> That said, ICANN generates the root zone including the servers
> declared authoritative for the zone.

Nope.

Verisign maintains them under contract to ICANN and NTIA and under
direction from ICANN. If ICANN told Verisign to make a change they
really didn't want to make, Verisign has just enough wiggle room to
delay until the NTIA rep can weigh in. Generally, though, ICANN
administers, Verisign implements and NTIA funds the effort.

> So they do have an ability to
> say: nope, you've crossed the line to any of the root operators.

ICANN as the IANA Functions Operator maintains the database of TLD info.
They provide this to Verisign, the Root Zone Maintainer, who create the
root zone and distribute it to the root server operators. Verisign does
this under a contract with NTIA, one of the few bits of the Internet that
is still under a US government contract:

Verisign Cooperative Agreement | National Telecommunications and Information Administration

This contract is also a part of the story:

https://www.icann.org/iana_imp_docs/129-root-zone-maintainer-service-agreement-v-28sep16

Absent interdiction from NTIA it gives ICANN the authority to direct
Verisign to do exactly what I said. And Cogent disconnecting the C
servers from a sizable part of the Internet is almost certainly
sufficient excuse to do it on an "emergency" basis without soliciting
comment.

Should ICANN attempt to mess with the distribution of the root zone, let
us just say that the results would not be pretty.

Fair. Whether they could, politically, make it stick is a whole other
can of worms.

I'm not guessing here, I go to ICANN meetings and talk to these people.

And you've been around since the early days too, but the documents
don't always match the talk. The talk reflects intentions. Intentions
change faster than contracts when something puts pressure on the
system.

Regards,
Bill Herrin

13

They have a similar problem in Africa with the major African IP Transit providers; and they are far less deployed in Africa than they are in Asia.

Mark.

14

This seems awfully simplistic, 'Cogent at 100% fault, in each case'.
It doesn't match my understanding, and therein lies the problem. In my
understanding of the issues, in a few of them, I would rate 100% fault
at the other side.

What are we asking in terms of your proposed policy change of allowing
host a root DNS? You must peer with everyone and anyone, at any terms?
I think we would struggle to form policy to capture the problem in a
fair and equitable manner.

As long as our toolbox only has a capitalist hammer, peering disputes
are going to be a thing. Cogent has outlived many of its peering
dispute history partners. They are the grandfather of disruptive
transit pricing, which many others have struggled to meet profitably,
and I believe they are a big reason for current transit pricing being
as low as it is in the US and EU.

15

Or to put it another way, if the community thought Cogent was not providing some value to them, they would no longer be in business. Mark.

16

Well, putting aside Cogent per se, and focusing on this much more interesting issue, I would suggest that this is already a well-established best practice, and reasonable in principle:

A-root, Verisign, open peering policy: AS7342 - Verisign - PeeringDB

B-root, USC/ISI, doesn’t really peer, but open in principle: B-Root Statement on Responses

C-root, Cogent, selective, not obviously published?

D-root, UMD, open peering policy: Peering with Packet Clearing House | PCH

E-root, NASA, open peering policy: Peering with Packet Clearing House | PCH

F-root, ISC, open peering policy: BGP Peering - ISC

G-root, DISA, doesn’t really peer

H-root, US Army, doesn’t really peer

I-root, NetNod, open peering policy: Peering with Netnod | Netnod

J-root, Verisign, open peering policy: AS7342 - Verisign - PeeringDB

K-root, RIPE, open peering policy: K-root Peering Policy — RIPE Network Coordination Centre

L-root, ICANN, selective: ICANN Managed Root Server | ICANN DNS Engineering

M-root, WIDE, open peering policy: AS7500 - M-ROOT DNS Server - PeeringDB

So, of the thirteen root nameservers, ten are potentially available for interconnection, and of those, only two, Cogent and ICANN, don’t have open peering policies.

So, yes, I think having an open peering policy should be a requirement for operating a root nameserver. I don’t think there’s any defensible rationale that would support root nameservers being a private benefit to be used to worsen the digital divide or create leverage in commercial disputes. They should, indeed, all be accessible to all networks.

                                -Bill

17

What type of network reach is required? Is single pop enough, that as
long as you have single pop, and open policy to peer with anyone who
wants to connect to your pop, you qualify?

18

IIUC, most of L-root's systems are hosted within transit networks, and not at IXPs. As such they have no control over additional peerings.

According to their PeeringDB entry, at all of the 23 IXPs listed they only peer via route servers and not bilaterally.

As such I don't think it's entirely fair to call them out on this.

Ray

19

According to their PeeringDB entry, at all of the 23 IXPs listed they only peer via route servers and not bilaterally.
As such I don't think it's entirely fair to call them out on this.

I’m not “calling them out,” I’m merely repeating their own assertion of their status, as they’ve put it on PeeringDB. They say they have a selective peering policy rather than an open peering policy. The other have open peering policies. The question was regarding open peering policies, and that’s what I was addressing. It’s not for me to judge whether organizations policies are what they claim, I’m only addressing the claim.

Most of L-root's systems are hosted within transit networks, and not at IXPs. As such they have no control over additional peerings.

Speaking for PCH, we explicitly do not do that because it aggravates the digital divide. (In addition to being a technically inferior solution, but it’s an easy shortcut to “having lots of dots on the map,” if that’s your goal.) Placing a server within a market-dominant network gives that network an additional anticompetitive lever to use to compel payments from its competitors. For a for-profit network, that’s a perfectly reasonable trade-off to make, and is undoubtedly good for short-term shareholder returns. For something that should be public-benefit network, it’s counterproductive.

Anyway, I thought the conversation was about Cogent, which is about as clearly in the for-profit camp as it’s possible to be.

                                -Bill

20

The topic of the conversation was Cogent, and this question doesn’t apply to them. We have to recognize that there are a limited number of public-benefit entities with the mission or budget to operate global-scale Internet public infrastructure, and that’s ok; it is what it is. Different models give us diversity and resilience, and that’s good. The thought I was expressing was about a moral principle that costs nothing to adhere to, I’m not interested in drawing a “you must be this tall to ride” line.

                                -Bill