Legend speaks of a well known BGP community referred to as 'no export',
which causes people with no direct connections to $carrier to not
have to listen to all that extra junk while still engineering inbound
traffic w/ more specifics for people who peer directly in diverse
locations. Amazing!
Indeed, I know from personal experience the heartbreak of supplying
no-export to a BGP peer who does not honor it, and propagates the
more-specific prefixes that I give them globally.
> 2. Cut-outs for those pesky dot-coms; you know, the ones with the most
> compelling content on the Internet jumping up and down in your face
> with a need to multi-home their /24 to satisfy the crushing global
> demand for such essentials as "the hamster dance."Ignoring inconsistent-as for a moment, the hamster dance multihoming
doesn't make the parent upstream need to _originate_ anything of the sort.
Presumably inconsistent-as is the only way that a more-specific
announced by a dual-homed customer would get charged to an origin AS
on Tony's list; in such a case (and on reflection, it is much more of
a corner case when inconsistent-as is involved, as you are correctly
pointing out), the parent that provided the address space would need
to originate that announcement if they wanted any of the traffic
toward that prefix to use their network.
Looking at "show ip bgp inconsistent-as," the number of prefixes that
would be charged to Tony's list for AS701 as an origin is certainly
small, if not non-existent.
Ignoring the specifics of Tony's list for a moment, it has been
pointed out in a couple NANOG presentations that the cut-outs
associated with dual-homing (yes, the _propagated_ ones, as opposed to
the _originated_ ones) are major contributors to recent routing-table
growth. Given AS701's footprint, it's hard not to imagine them seeing
more of that kind of thing than most.
Stephen