yes --Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ####################################################### On Fri, 12 Jul 2002, Phil Rosenthal wrote:

Wow, I feel stupid now, they actually have a /9.

Ignore me ;) --Phil

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Phil Rosenthal Sent: Friday, July 12, 2002 10:24 PM To: nanog@merit.edu Subject: No one behind the wheel at WorldCom

BGP routing table entry for 63.0.0.0/9, version 7001923 Paths: (5 available, best #1, table Default-IP-Routing-Table) Advertised to peer-groups: customer Advertised to non peer-group peers: 209.123.37.30 701 157.130.9.141 (metric 65024) from 209.123.11.10 (209.123.12.59) Origin IGP, localpref 300, valid, internal, best Community: 8001:666 8001:701 701 157.130.9.141 (metric 65024) from 209.123.11.245 (209.123.12.59) Origin IGP, localpref 300, valid, internal Community: 8001:666 8001:701 8001 7911 3561 701 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 200, valid, external Community: 8001:666 8001:7911 7911 3561 701, (received-only) 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 100, valid, external 15036 16631 174 701 209.123.37.30 from 209.123.37.30 (209.123.132.181) Origin IGP, localpref 100, valid, external Community: 8001:666 8001:16631 15036:0 15036:666 15036:16631 16631:1000

From: http://eng.nac.net/lookingglass/nyc.html Bgp: 63.0.0.0

Uunet has been announcing this for more than 2 days now. (not sure when since I cleared my bgp tables 2 days ago).

--Phil

I beg to differ... c/o Tony Bates, UU are only kept off the top spot by Telstra's apparent policy of deaggregating! 1) Gains by aggregating at the origin AS level --- 05Jul02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS701 1234 987 247 20.0% UUNET Technologies, Inc. AS7046 313 230 83 26.5% UUNET Technologies, Inc. AS702 519 473 46 8.9% UUNET Technologies, Inc. On Sat, 13 Jul 2002, Christopher L. Morrow wrote:

Hmm.. I MIGHT be wrong here, but both:

63.0.0.0/10 and 63.64.0.0/10 are registered to UUNET (arin blocks: NETBLK-NETBLK-UUNET97DU & NETBLK-UUNET63 )

These add up to 63.0.0.0/9, right? I mean, we DO want to aggregate this, right?

--Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################

On Fri, 12 Jul 2002, Phil Rosenthal wrote:

...

BGP routing table entry for 63.0.0.0/9, version 7001923 Paths: (5 available, best #1, table Default-IP-Routing-Table) Advertised to peer-groups: customer Advertised to non peer-group peers: 209.123.37.30 701 157.130.9.141 (metric 65024) from 209.123.11.10 (209.123.12.59) Origin IGP, localpref 300, valid, internal, best Community: 8001:666 8001:701 701 157.130.9.141 (metric 65024) from 209.123.11.245 (209.123.12.59) Origin IGP, localpref 300, valid, internal Community: 8001:666 8001:701 8001 7911 3561 701 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 200, valid, external Community: 8001:666 8001:7911 7911 3561 701, (received-only) 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 100, valid, external 15036 16631 174 701 209.123.37.30 from 209.123.37.30 (209.123.132.181) Origin IGP, localpref 100, valid, external Community: 8001:666 8001:16631 15036:0 15036:666 15036:16631 16631:1000

From: http://eng.nac.net/lookingglass/nyc.html Bgp: 63.0.0.0

Uunet has been announcing this for more than 2 days now. (not sure when since I cleared my bgp tables 2 days ago).

--Phil

I beg to differ...

c/o Tony Bates, UU are only kept off the top spot by Telstra's apparent policy of deaggregating!

I don't speak for UUNET, not a shareholder, don't have any say over their routing policies; that said, there are a couple reasons that might be the case: 1. Deaggregation to help spread out traffic flow. As someone who used to send a lot of traffic toward some big providers, it can be hard to balance traffic efficiently when all you get is one short prefix at multiple peering points. Having more-specifics, and possibly even MEDs that make sense, can help with decisions regarding which part of a /9 can be reached best via which peering point. (And that's peering as in BGP, not peering as in settlements.) 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." I can easily imagine that when you have a lot of customers (as UUNET is purported to have), you'd have the above two situations in spades, plus more that we'll no doubt discuss at great length for the next week. Let's consider the converse, though - what if AS701 were to suddenly become a paragon of routing table efficiency, and collapse all their announcements into one (not possible, I know, but indulge me, please)? First, some decrease in revenue because all the more-specifics for multi-homed customers would be preferred over the one big AS701 announcement. Second, a traffic balancing nightmare as everyone who touches AS701 in multiple places tries to figure out how to deliver traffic to AS701 efficiently. While Tony's report certainly indicates that things could be better, it is also true that they could be a lot worse. Stephen

...

1. Deaggregation to help spread out traffic flow. As someone who used to send a lot of traffic toward some big providers, it can be hard to balance traffic efficiently when all you get is one short prefix at multiple peering points. Having more-specifics, and possibly

A slight exaggeration, large providers have more than one assignment of IPs and according to the RIR info they are used regionally anyway

Yes, but as the prefix length gets shorter, you lose visibility into how traffic might efficiently be divided up among the points at which a prefix is offered (whether you listen to MEDs or manipulate metrics yourself). Treating North America as a region, a provider might announce a /8 at five different places in that region. For any given point, you might be trying to reach a more-specific that's in the same city, or across the continent. To the extent that providers announce longer prefixes because that's what the RIRs gave them, and practice allocation policies that concentrate use of that space topologically within their network, yes, your comment is a sensible refinement of mine. The practice of announcing more-specifics to help peers with traffic engineering is certainly in use today (just as the practice of not doing so is in use today); the extent to which that puts AS701 where it is on Tony's list is something I don't know. I'm assuming, though, that application of that practice by AS701 would cause them to be higher on Tony's list than if they did not engage in that practice. Whether AS701 thinks that way or not is up to AS701 folks to say (or not).

...

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."

Overlap the more specific with the main block? (I assume) Tony's report shows originating AS, in which case the sub-assignments wont show towards UUs count.

I was making the assumption that longer prefixes within a shorter one did contribute to what Tony is counting.

...

Let's consider the converse, though - what if AS701 were to suddenly become a paragon of routing table efficiency, and collapse all their announcements into one (not possible, I know, but indulge me, please)?

First, some decrease in revenue because all the more-specifics for multi-homed customers would be preferred over the one big AS701 announcement.

They will still announce the customer's BGP more specifics tho?

You're applying reality to the example. This is a contrived example to illustrate the end of the spectrum where AS701 emits one very short prefix - kind of like some IPv6 people seem to think that inter-provider routing should work (to use a current analogy).

...

Second, a traffic balancing nightmare as everyone who touches AS701 in multiple places tries to figure out how to deliver traffic to AS701 efficiently.

As above, it is at least as far as I can tell assigned per country.

What do countries have to do with this? AS701 is UUNET's North American (for the most part) AS number. It is possible to have a handful of attachments to it within the United States alone. As noted above, if AS701 were to announce a short prefix with no more-specifics at several points, your options to efficiently balance traffic among those points are less than if you were supplied with more-specific prefixes that give you clues as to how the short prefix is partitioned internally (say, east-coast US vs. west-coast US). Stephen

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

On Sat, 13 Jul 2002, Stephen Stuart wrote:

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.

I'm wondering how many folks out there choose not to honor this community and why. If anyone on the list chooses not to I'd be interested to hear (either on-list or off) the reasonings behind it. Paul

On Sat, Jul 13, 2002 at 04:00:42PM -0700, Stephen Stuart wrote:

Please also respond if you weren't aware that you have to explicitly implement the policy of honoring no-export - while the community vaue is "well-known," the policy is not built-in.

If you do not wipe out the communities that you receive, then no-export works as expected. But if you have a route-map or import policy that explicately removes or overwrites all received communities, then no-export is deleted as well, and thus does not do anything. --asp