Cogent-TATA peering dispute?
It would appear that ( as of yesterday ) some but not all BGP routes between Cogent and TATA are gone.
From my own observations it seems like all TATA Routes in APAC and 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: https://atlas.ripe.net/measurements/71894623#probes
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?
On Fri, May 17, 2024 at 9:55 AM Ben Cartwright-Cox via NANOG <nanog@nanog.org> wrote:
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: https://atlas.ripe.net/measurements/71894623#probes
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
Not even the first time tata and cogent separated. Will avoid public details but I was on the keyboard at 6453 that time. On Fri, May 17, 2024, 6:05 PM William Herrin <bill@herrin.us> wrote:
On Fri, May 17, 2024 at 9:55 AM Ben Cartwright-Cox via NANOG <nanog@nanog.org> wrote:
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: https://atlas.ripe.net/measurements/71894623#probes
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, May 17, 2024, 6:05 PM William Herrin <bill@herrin.us> wrote: For those who haven't been around long enough, this isn't Cogent's first depeering argument. Nor their second.
They’re also still in the middle of one with NTT. https://en.wikipedia.org/wiki/Cogent_Communications#Peering_disputes -Bill
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
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
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, May 17, 2024 at 4:28 PM John Levine <johnl@iecc.com> wrote:
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?
There is no contract for running root servers and never has been.
I stand corrected. https://www.netnod.se/dns/dns-root-server-faq 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 -- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, 17 May 2024, William Herrin wrote:
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: https://www.ntia.gov/page/verisign-cooperative-agreement 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
On May 18, 2024, at 03:53, John R. Levine <johnl@iecc.com> wrote: On Fri, 17 May 2024, William Herrin wrote:
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:
https://www.ntia.gov/page/verisign-cooperative-agreement
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.
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
On Fri, May 17, 2024 at 6:53 PM John R. Levine <johnl@iecc.com> wrote:
On Fri, 17 May 2024, William Herrin wrote:
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:
This contract is also a part of the story: https://www.icann.org/iana_imp_docs/129-root-zone-maintainer-service-agreeme... 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 -- William Herrin bill@herrin.us https://bill.herrin.us/
John, On May 17, 2024, at 6:53 PM, John R. Levine <johnl@iecc.com> wrote:
ICANN as the IANA Functions Operator maintains the database of TLD info.
Sort of.
They provide this to Verisign, the Root Zone Maintainer, who create the root zone and distribute it to the root server operators.
Technically, IANA provides database change requests to Verisign. The actual database is maintained by the Root Zone Maintainer (hence the name).
Verisign does this under a contract with NTIA, one of the few bits of the Internet that is still under a US government contract:
Err, no. You forgot the little bit about the IANA Functions transition. Specifically: https://www.icann.org/en/stewardship-implementation/root-zone-maintainer-agr...
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.
When you say “ICANN” who, exactly, do you mean? ICANN the organization or ICANN the community? If the former, ICANN Org can’t do anything outside of ICANN community defined policy or process or risk all sorts of unpleasantness from internal policies to lawsuits to the ICANN Board being spilled. If you mean the latter, ICANN org must abide by the ICANN community’s demands or you get to the same point as previously mentioned. That’s the whole point behind the “Empowered Community."
I'm not guessing here, I go to ICANN meetings and talk to these people.
And I was one of the ICANN people involved in the negotiations with Verisign on the RZMA. Regards, -drc
On Sun, 19 May 2024, David Conrad wrote:
They provide this to Verisign, the Root Zone Maintainer, who create the root zone and distribute it to the root server operators.
Technically, IANA provides database change requests to Verisign. The actual database is maintained by the Root Zone Maintainer (hence the name).
Good point. In any event, I think we agree that none of IANA, ICANN, and/or Verisign has the authority to remove one of the root operators, no matter how much someone might dislike their peering policies. R's, John PS: Perhaps the GWG will eventually come up with a way to do that but I'm not holding my breath. It's been six years since RSSAC 037 and 038. I can't blame them for moving very slowly since it would be all too easy to come up with something worse than the current non-system
John, On May 19, 2024, at 12:53 PM, John R. Levine <johnl@iecc.com> wrote:
On Sun, 19 May 2024, David Conrad wrote:
They provide this to Verisign, the Root Zone Maintainer, who create the root zone and distribute it to the root server operators.
Technically, IANA provides database change requests to Verisign. The actual database is maintained by the Root Zone Maintainer (hence the name).
Good point.
In any event, I think we agree that none of IANA, ICANN, and/or Verisign has the authority to remove one of the root operators, no matter how much someone might dislike their peering policies.
Yes. While technically, there is the capability (they are, after all merely entries in a database that get dumped into a file), the question of authority (ignoring court order) is less clear cut and certainly does not reside in ICANN org, PTI, or Verisign. Regards, -drc
On 5/19/24 3:13 PM, David Conrad via NANOG wrote:
When you say “ICANN” who, exactly, do you mean? ICANN the organization or ICANN the community? If the former, ICANN Org can’t do anything outside of ICANN community defined policy or process or risk all sorts of unpleasantness from internal policies to lawsuits to the ICANN Board being spilled. If you mean the latter, ICANN org must abide by the ICANN community’s demands or you get to the same point as previously mentioned. That’s the whole point behind the “Empowered Community."
Suppose the community wanted to change this or make a formal policy on root server hosting requirements. Where would this be done? Could a party submit a proposal to ICANN via the policy development process? If not where should the community start this? Please note, I'm not taking a position, only asking where the community needs to start. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
On May 19, 2024, at 1:12 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
Suppose the community wanted to change this or make a formal policy on root server hosting requirements. Where would this be done? Could a party submit a proposal to ICANN via the policy development process? If not where should the community start this?
That’s exactly what the Root Server System Governance Working Group (https://community.icann.org/pages/viewpage.action?pageId=120820189) is trying to figure out. As John has noted, it has been going on for 6+ years now. See RSSAC-037 (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) and RSSAC-058 (https://www.icann.org/en/system/files/files/rssac-058-17nov21-en.pdf). In the past, the IETF has issued RFCs on the topic (RFCs 2010, 2870, and 7720) and the root server operators have made various commitments related to “service expectations” documented in ICANN's RSSAC document series (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectati...), but as has been pointed out, those commitments are contractual or otherwise binding obligations. Regards, -drc
Oops. Missed a (significant) word. On May 19, 2024, at 3:02 PM, David Conrad via NANOG <nanog@nanog.org> wrote:
On May 19, 2024, at 1:12 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
Suppose the community wanted to change this or make a formal policy on root server hosting requirements. Where would this be done? Could a party submit a proposal to ICANN via the policy development process? If not where should the community start this?
That’s exactly what the Root Server System Governance Working Group (https://community.icann.org/pages/viewpage.action?pageId=120820189) is trying to figure out. As John has noted, it has been going on for 6+ years now. See RSSAC-037 (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) and RSSAC-058 (https://www.icann.org/en/system/files/files/rssac-058-17nov21-en.pdf). In the past, the IETF has issued RFCs on the topic (RFCs 2010, 2870, and 7720) and the root server operators have made various commitments related to “service expectations” documented in ICANN's RSSAC document series (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectati...), but as has been pointed out, those commitments are contractual or otherwise binding obligations.
“… are NOT contractual or otherwise binding obligations.” Regards, -drc
It appears that Bryan Fields <nanog@nanog.org> said:
Suppose the community wanted to change this or make a formal policy on root server hosting requirements. Where would this be done? Could a party submit a proposal to ICANN via the policy development process? If not where should the community start this?
The Governance Working Group that David mentioned has been grinding along for the better part of a decade. It's quite a difficult problem. The existing roots are doing a decent job, and any more formal arrangement runs the risk of politically motivated "improvements". People are worried about what happens if a root goes rogue or disappears but unless the rogue operator were Verisign, which is utterly implausible, the result would be not much. These days a lot of web caches have their own copies of the root that they get directly from ICANN or Verisign. (See RFC 8806. It's really easy.) For everyone else, most clients now make DNSSEC queries and the root's signatures expire after two weeks. I would be a lot more worried about the other scenario David hinted at, a future iteration of the US government tells ICANN or Verisign to do something to the root zone, e.g., delete Iran or Russia or point their name servers at something else. https://community.icann.org/pages/viewpage.action?pageId=120820189 R's, John
On May 18, 2024, at 02:30, William Herrin <bill@herrin.us> wrote: 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.
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
On May 17, 2024, at 10:14 PM, Bill Woodcock <woody@pch.net> wrote:
On May 18, 2024, at 02:30, William Herrin <bill@herrin.us> wrote: 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.
As John said, ICANN has nothing to do with who runs root servers.
Wrong in 2 ways: 1) ICANN runs one of root servers. 2) https://community.icann.org/pages/viewpage.action?pageId=120820189
Last I knew, NTIA still believed that NTIA selects the root server operators.
I doubt even NTIA would _ever_ have said this, and certainly not since the IANA Functions transition. This is simply not how the relationship between NTIA and ICANN operated (pre-transition, after transition it is even less).
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.
Interesting theory. Regards, -drc
On Fri, 17 May 2024, William Herrin wrote:
On Fri, May 17, 2024 at 9:55 AM Ben Cartwright-Cox via NANOG <nanog@nanog.org> wrote:
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: https://atlas.ripe.net/measurements/71894623#probes
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.
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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 5/18/24 06:04, Jon Lewis wrote:
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.
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.
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 On 5/17/2024 at 5:06 PM, "William Herrin" <bill@herrin.us> wrote:
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?
On Sat, 18 May 2024 at 01:07, William Herrin <bill@herrin.us> wrote:
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.
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. -- ++ytti
On 5/18/24 08:56, Saku Ytti wrote:
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.
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.
On May 18, 2024, at 08:56, Saku Ytti <saku@ytti.fi> wrote: 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?
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: https://www.peeringdb.com/net/873 B-root, USC/ISI, doesn’t really peer, but open in principle: https://b.root-servers.org/statements/response.html C-root, Cogent, selective, not obviously published? D-root, UMD, open peering policy: https://www.pch.net/peering E-root, NASA, open peering policy: https://www.pch.net/peering F-root, ISC, open peering policy: https://www.isc.org/froot-peering/ G-root, DISA, doesn’t really peer H-root, US Army, doesn’t really peer I-root, NetNod, open peering policy: https://www.netnod.se/about-netnod/peering-with-netnod J-root, Verisign, open peering policy: https://www.peeringdb.com/net/873 K-root, RIPE, open peering policy: https://www.ripe.net/analyse/dns/k-root/k-root-peering-policy/ L-root, ICANN, selective: https://www.dns.icann.org/imrs/ M-root, WIDE, open peering policy: https://www.peeringdb.com/asn/7500 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
On Sat, 18 May 2024 at 10:38, Bill Woodcock <woody@pch.net> wrote:
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.
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? -- ++ytti
On May 18, 2024, at 11:55, Saku Ytti <saku@ytti.fi> wrote: On Sat, 18 May 2024 at 10:38, Bill Woodcock <woody@pch.net> wrote:
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.
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?
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
On 18/05/2024 08:38, Bill Woodcock wrote:
L-root, ICANN, selective: https://www.dns.icann.org/imrs/
...
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.
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
On May 18, 2024, at 19:30, Ray Bellis <ray@bellis.me.uk> wrote: 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
participants (13)
-
Ben Cartwright-Cox -
Bill Woodcock -
Bryan Fields -
David Conrad -
jim deleskie -
joenanog＠nym.hush.com -
John Levine -
John R. Levine
-
Jon Lewis -
Mark Tinka -
Ray Bellis -
Saku Ytti -
William Herrin