On Sat, Oct 08, 2005 at 04:54:52AM -0700, Eric Louie wrote:
DISCLAIMER: From one of the clueless
During this entire debaucle, I never saw any mention of:
1) Cogent sending "transit" traffic to Level3, which leads me to believe that all the traffic from Cogent through the peering points was actually *destined* for Level3 customers. Does the routing support this idea? Is it safe to assume the opposite, also... that only traffic destined for Cogent customers came through the Level3 peering points? And that Level3 had one and only one path to Cogent (no one else providing transit for them to Cogent AS'es?)
Neither Level3 nor Cogent utilize a middleman called "transit" to reach each other. Sure, Cogent has Verio as its transit, but Verio is used as a partial transit to only reach some spot nets (e.g. Sprint, France Telecom, ATDN, etc). You may want to better understand the difference between a transit relationship and a peering relationship. Here is exerpt from wbn's Equinix paper: 8<--- Transit is the business relationship whereby one ISP provides (usually sells) access to all destinations in its routing table. --->8 (Note: Also several ISPs offer "regional transit" or "limited/partial transit", by providing regional routes instead of full routing table access. Cogent's Verio transit service is partial transit.). 8<--- Peering is the business relationship whereby ISPs reciprocally provide access to each others' customers (no access to whole internet is provided). --->8
2) Level3 making any contingency for their own customers to reach Cogent networks (any announcements to their own customers)
This is unheard of unfortunately to date. But as mentioned, Cogent has made numerous contacts through sales channel to accomodate customer needs before the disconnection.
3) Possible traffic issues. Was Cogent guilty of not transporting the Level3-bound packets within the Cogent network to the closest point-of-entry peer to the host in the Level3 network, therefore "costing" Level3 transit of their own packets? In other words is it also a traffic engineering issue?
No, that was BBN vs. Exodus depeering superbowl back in 90's, which was resolved through cold potato routing. Level 3 claims Cogent is sending far more traffic than Level3 to Cogent. Thus, Level3's viewpoint is that Cogent relies on them more than they rely on Cogent. Thus, it no longer makes sense in their view point to maintain a free interconnection as there is no similar balance of traffic ratio. Cogent claims Level3 depeered because of competingly low market prices for transit bandwidth sold by Cogent. Cogent further claims that it is Level3 who requested Cogent to send more traffic. So... which side is really true, no one knows at this point, but these are what both sides are stating.
Are some of the business issues solvable by proper engineering and filtering (or statistics-jockeying)?
Yes and no. Cogent could technically deprefer Level3 peering partially or totally to reduce the egress traffic to Level3 peering. Since many of Level3 customers are multihomed, deprefering Level3 peering to certain extent would cause significant chunk of bits to reroute to Cogent's other peers who are providing additional transit to said customers. But you have to realize though that often times, significant peering disputes arise from business and political related issues, not technical. There are lot of technical peering disputes going on everyday, and majority of those can be resolved quietly without even impacting users other than a "scheduled maintenance" event. The current depeering dispute is really more or less "desperation depeering" as Richard pointed out. Thus it is not necessarily initiated by technical disputes that can be resolved using traffic engineering, but trying to see who blinks and pays up. Some may call it "extortion", some may call it "the depeeree deserved it" or some may call it "both sides burning bridges." and other views, etc.. James -- James Jun Infrastructure and Technology Services TowardEX Technologies Office +1-617-459-4051 x179 | Mobile +1-978-394-2867 james@towardex.com | www.towardex.com