On Sat, 12 Feb 2005, Stephen J. Wilcox wrote:
this is getting into what i was implying earlier.. you have wider experience than me - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and dont even realise they could fix it.. that applies to medium and large providers too reading this list - how often do they actually check what prefixes they are sourcing, from my recent work at a couple of european IXes i had a number of folks email me offlist as they hadnt realised til I sent out an email they had deaggregation and once it was pointed out they just fixed it.
so to repeat my earlier suggestion - if transit providers, particularly the larger ones setup scripts to notify their customers daily/weeks of routing deaggregation do you think we might gain some traction in educating and fixing this?
Why does it have to be transit providers (customer relationship, so it's not spam? :) Anyone could look at the global table (or just take the CIDR Report data) and automate emailing the ASN contacts for each ASN a list of what they're announcing and a list of the routes they probably should be announcing instead. I've personally dealt with a customer not too long ago who when we turned them up was announcing 2 /20s, a /21, a /22, and several /23s and /24s all deaggregated as /24s. Sprint and Qwest (their other upstreams at the time) apparently had no problem with this. I saw what they were doing and asked them why. "That's how our router consultant set it up." There was no technical reason for it. I helped them reaggregate their BGP announcements. I'll bet there are at least hundreds of similar AS's that just need to be prodded (or maybe even some hand holding or config help) in order to clean up their announcements. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________