Re: [pacnog] Splitting up prefix advertisements

[Philip Smith <pfs@cisco.com>]

Hi Alo,

Alo Anesi said the following on 14/7/06 20:00:
>
> So from everything we discusses at the previous PACNOGs, it seems splitting
> up prefix advertisements is the best (only?) way to split inbound traffic
> when dealing with two different upstreams.

It's pretty much the only way unfortunately. No BGP implementer has
support for the no-peer community (RFC3765); that would have helped with
hiding local traffic engineering requirements of providers.

> My question is, can I go as far as splitting at the /22 boundary for my /20?
> I could split at the /21 boundary, but with the way we've been allocating
> customer addresses 90% of my usage occurs in the first half of my /20.

Well, you could subdivide all the way down to a /32 if you really wanted
to, but I really wouldn't bet anything on reachability of those
specifics if you do that. It is really important to always announce your
aggregate, even if you subdivide the block for traffic engineering purposes.

The other thing that very few people think about is how they do the
address assignments within their own backbone. If 90% of the traffic
comes into 5% of the address space, I'd encourage people to consider
renumbering to make the load balancing easier. Dynamic assignment pools
are easy to renumber, so if you need to move internal address space
usage around to help with load balancing, that's one possible target (I
did that years ago in my operational days).

> I realize the CIDR folks may frown on de-aggregation, but I need some way
> to load balance two links of different sizes from 2 different upstreams.

As one of the "CIDR folks", I frown on unnecessary deaggregation. I
reckon that 35% of the address space announced is simply people
announcing their address blocks split unnecessarily into /24s -
basically what I call leaking their internal BGP prefixes to the public
Internet. Internal BGP is only meant to be visible inside an Autonomous
System - external BGP has a different purpose, and that's where all SPs
need to be prudent. So careful deaggregation to assist with traffic
engineering is just one of those facts of life - but Alo, please don't
take your /20 and spray it out to the world as 16 /24s with random
AS-PATH prepends to do your load balancing. There are many better ways,
e.g. as per the PacNOG workshop materials from the last meeting.

philip
--