On 19 Jan 2005, at 13:57, Gordon Smith wrote:

What can cause issues is if you then start creating routing policies on your route reflectors based on AS-path, especially if you don't have a direct peer with both of the providers that are carrying that customer's traffic. With multiple peering points, you can end up backhauling the traffic over your own links because the routing decisions passed via your IGP are no longer necessarily optimal e.g. I may wish to pass a 10Mbit stream from a Wellington customer to somewhere else in Wellington, via another provider, but the route reflectors see that destination as having a shorter AS path via Auckland. We don't have a destination AS that a metric can be applied to. We can of course apply different costs to the WAN links (and should have done), but the fine-grained control of traffic isn't achievable because the router can't be given much to go on.

It's hard to decrypt this precisely without having a whiteboard in front of us (and a bottle of beer in each hand) but it sounds like you're talking about the problem of mapping cost into routing policy in order to optimise your exit selection. AS_PATH length in a densely-peered environment like New Zealand is a pretty crude hammer. You would probably do well to look harder at BGP's path selection algorithm and see whether there's an alternate discriminator you can use which will do the right thing more often. In general, though, the bad news is that if your cost analysis includes costs of shifting traffic within your own network, and if you peer with other ASes in multiple places, there is no magic bullet which will make everything work the way you want, all the time. You're going to be engaging in an ongoing iterative process of observation, measurement and tweaking if you want to keep everything flowing the way you think it should. There are some vendors who sell boxes which are designed to automate this process -- boxes which participate in your internal routing protocols and adjust attributes in routes according to measurements made across the network to try and pull traffic away from congested/latent/undesirable paths. I haven't tried any of them, but I know people who swear by them (by, not at). The import filters you deploy at your edge are up to you -- if you decide to deny paths because they contain a private-use ASN, or because their origin AS seems inappropriate, then that's perfectly right and proper. You *should* be doing your own thing -- that's what autonomous means. By the same token, however, telling other people to change the way they run their networks in order that your life be made easier may not work as well as you hope (unless there's something in it for them, like improved performance for their customers, or reduced costs, or beer, or something).

APNIC have always been very good when it comes to getting ASN's; I've always found the justification of additional address space to be an ordeal though :-)

This seems to be the common wisdom. By contrast, I've always found the process of applying for additional address space to be wildly simple and straightforward. People who think it's difficult should sit down with some of the APNIC people in Hamilton and tell them why, maybe.

In my opinion, it would be far more preferable if APNIC allocated an ASN when a customer was given an independent address assignment. After all, the reason that most want independantly allocated space is to multihome...

I think the reason most people want provider-independent address space is so that they can change providers without renumbering, actually. You don't need PI addresses in order to multihome (see <http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming -03.txt> for more discussion). Joe