Quite a bit of this data has been published by several of the principles involved for quite some time. They haven't been shy about answering questions and talking.
I have to sugest that you should re-read the sentence you quote in its context- I don't understand how the sentence quoted is in any way related to your comment about it. Labovitz is saying that it is difficult to accurately charachterize exactly all the bad things that are going on out there, in part because the bad things are happening in places that shouldn't exist and are therefore off of many peoples radar.
In answer to your question- it depends, but certainly in some cases- yes.
Route-filters help address this, but many people don't do aggressive route filtering. Route filters, at least in this context, allow you to describe which route announcements you will accept from who. You typically write route-filters to *only* listen to route announcements for the networks that the person you are peering with owns. If its a multihomed connection then this can be a pain. If its an ISP (especially a multihomed one with multihomed customers) it becomes even more of a pain and becomes a matter of trusting your peers to enforce the right policies at the edge of their network. Some people do things with BGP communities to make this easier, but many folks do not have the clue to do so.
As mentioned earlier in the article, aggressive route filtering can actually increase the discontinuties in the network, but failing to do the right filtering can create opportunities for antisocial/malicious behavior.
There were attempts, with some success to create truly useful route registries- the radb's. MCI and someone else (I'm pretty sure it was the route-arbiter project folks- in which Abha [from this report] played a significant role) maintained these. Some people used these to auto-create route filters, but I think that all got just to darn complicated. I could be totally wrong about this, but that's my recollection.
Not to rant (to late), but to my way of thinking this all is rooted in a basic issue with large multi-entity IP networks- a peer isn't just someone you exchange traffic with for free [or with settlements] it really is a *peer*. By exchanging routing information (especially if you do something like accept/honor MED's) you really do have to trust these people- that means you have to believe they are as competent or moreso than yourself- in other works, a peer- in the truest sense of the word. With extremely democratic large scale IP networks (like the Internet) the meaning and usefullness of the term peer becomes significantly diluted- and this means that the network as a whole is likely to not function at a fully optimized state (or even a merely completely working state) all/most of the time. That isn't a horrible thing, but it certainly does make you reevaluate certain assumptions many people make about IP networks.
Further, I believe that most if not almost all of the "scaling" problems in the Internet today are not as much technical capability problems as configuration/design/education problems. We now have a giant, dynamic network that usually works quite well- can it fail catastrophically? I believe it *can*, but the size, interconnectiveness and diversity tends to locally contain failure conditions- events that would have been extremely catastrophic just a couple of years ago.
I'll stop "lecturing" now, except to say that it is great to see folks like these, CAIDA, Packet Design, and assorted others starting to really try to formalize analysis methods for networks of this complexity- its a great step forward from the cult-of-the-few-geeks (The Internet Routing Cabal wasn't that long ago- not to say they weren't great people who made lots of personal sacrifices to keep things working)
As a footnote, Craig L. and Abha A. have done other related work (before they were with Arbor Networks). I know they presented some of their work on BGP reconvergence time at the Montreal NANOG. I suspect they've presented since then.
Slashdot Mirror
Quite a bit of this data has been published by several of the principles involved for quite some time. They haven't been shy about answering questions and talking.
I have to sugest that you should re-read the sentence you quote in its context- I don't understand how the sentence quoted is in any way related to your comment about it. Labovitz is saying that it is difficult to accurately charachterize exactly all the bad things that are going on out there, in part because the bad things are happening in places that shouldn't exist and are therefore off of many peoples radar.
In answer to your question- it depends, but certainly in some cases- yes.
Route-filters help address this, but many people don't do aggressive route filtering. Route filters, at least in this context, allow you to describe which route announcements you will accept from who. You typically write route-filters to *only* listen to route announcements for the networks that the person you are peering with owns. If its a multihomed connection then this can be a pain. If its an ISP (especially a multihomed one with multihomed customers) it becomes even more of a pain and becomes a matter of trusting your peers to enforce the right policies at the edge of their network. Some people do things with BGP communities to make this easier, but many folks do not have the clue to do so.
As mentioned earlier in the article, aggressive route filtering can actually increase the discontinuties in the network, but failing to do the right filtering can create opportunities for antisocial/malicious behavior.
There were attempts, with some success to create truly useful route registries- the radb's. MCI and someone else (I'm pretty sure it was the route-arbiter project folks- in which Abha [from this report] played a significant role) maintained these. Some people used these to auto-create route filters, but I think that all got just to darn complicated. I could be totally wrong about this, but that's my recollection.
Not to rant (to late), but to my way of thinking this all is rooted in a basic issue with large multi-entity IP networks- a peer isn't just someone you exchange traffic with for free [or with settlements] it really is a *peer*. By exchanging routing information (especially if you do something like accept/honor MED's) you really do have to trust these people- that means you have to believe they are as competent or moreso than yourself- in other works, a peer- in the truest sense of the word. With extremely democratic large scale IP networks (like the Internet) the meaning and usefullness of the term peer becomes significantly diluted- and this means that the network as a whole is likely to not function at a fully optimized state (or even a merely completely working state) all/most of the time. That isn't a horrible thing, but it certainly does make you reevaluate certain assumptions many people make about IP networks.
Further, I believe that most if not almost all of the "scaling" problems in the Internet today are not as much technical capability problems as configuration/design/education problems. We now have a giant, dynamic network that usually works quite well- can it fail catastrophically? I believe it *can*, but the size, interconnectiveness and diversity tends to locally contain failure conditions- events that would have been extremely catastrophic just a couple of years ago.
I'll stop "lecturing" now, except to say that it is great to see folks like these, CAIDA, Packet Design, and assorted others starting to really try to formalize analysis methods for networks of this complexity- its a great step forward from the cult-of-the-few-geeks (The Internet Routing Cabal wasn't that long ago- not to say they weren't great people who made lots of personal sacrifices to keep things working)
As a footnote, Craig L. and Abha A. have done other related work (before they were with Arbor Networks). I know they presented some of their work on BGP reconvergence time at the Montreal NANOG. I suspect they've presented since then.
http://www.nanog.org/mtg-9910/converge.html