Re: BGP Private ASes

Andy Linton sent me this response, which he tells me he intended for nznog as well. Below is Andy's response, and then my reply to Andy's response. Both are at least as relevant to the list as discussing Klez all day :-) Andy's response: On Wed, 11 Sep 2002, Ewen McNeill wrote:

In message , "Arron Scott" writes:

...

I get endless number of customers who want to peer with more than one ISP at a time, usually with the intention of resiliency at both the institutional and upstream provider levels. [... Want Class C, public AS, advertised prefix... ] Now ... what I was thinking is ... can we do this without the rare (and increasingly difficult to obtain) Public AS numbers.

There are proposals to increase the size of the AS numbers from 16 to 32 bits but that soesn't solve the immediate difficulties in getting an AS number.

I'm also in touch with clients that would like to do this -- they don't especially care about the Class C, or Public AS, etc, but they would like some resiliency for any disconnections from their provider or routing issues for their provider, often because they have clients that have that as a tick-box feature.

I've heard some very interesting discussions about flap damping at the RIPE meeting this week. See http://psg.com/~randy/020910.zmao-flap.pdf. The important thing to note is that the thing that is damped is prefixes so dual homing may not give you all you hope for if flap damping is in use.

...

Could we have a publically agreed on pool of Private AS numbers that enterprises can use to peer with service providers. The pool would administered by a "impartial" group (maybe WIX/APE). The AS number would then be stripped by both higher-order ISPs and and the IP address potentially unsuppressed by the ISP who owns the IP address aggregate.

If I'm not mistaken about what you mean, this is what WIX (the route reflectors) are trying to do.

Dean Pemberton and I have been talking with Simon about trying to get WIX and APE whois servers running so that people could start registering routes and AS policy for RPSL use in NZ. Using these to allocate locally scoped private ASes for use on the WIX and APE would be a doddle.

The WIX approach seems to work, but: - it appears some providers do not peer with the WIX route reflectors, or do so only to advertise their routes, not to allow in extra routes

- most providers filter "long" prefixes (and most enterprises without public ASes tend to have only long prefixes). Certainly it's my impression that pretty much all providers filter anything longer than /24, and some appear to even filter /24, /23, /22, etc, meaning the prefixes advertised by enterprises are likely to be filtered.

It seems difficult to believe that the relatively small additional number of prefixes being announced by the enterprises on the WIX is significant. The total number of prefixes is around the 250 mark and many of those come from the "providers" anyway. Filtering out the few dozen prefixes that are /25 or greater would seem to have little impact on table size and the kosher ones could easily handled in a prefix-list.

So from an enterprise point of view WIX (the route reflectors) are useful for picking up direct routes to providers POPs, but this tends to lead to asymetric routes to/from the providers (and hence no real resiliency).

So it would be nice to get the providers to use them. Some of them resist but surely this is an issue that could be driven by their respective customers. E.g. "As my provider I need you to provide a resilient efficient local mesh at WIX and APE. Perhaps I should consider moving to a provider who...."

And it's useful for enterprise to enterprise peering (indeed one of my clients connected to the WIX route reflectors soley for the enterprise to enterprise peering; at the request of the other enterprise).

The WIX route reflectors (according to the route table on a router peering with them) appears to have about 50 systems peering with it at present.

But without providers willing to (a) peer with the route reflectors, and (b) accept long prefixes (at least locally), it's probably not going to be of general use for resiliency.

To be of much general use providers would have to be willing to at least accept /24 prefixes locally, even if they're part of a larger supernet advertised by another provider. Longer prefixes would be desirable, because otherwise anyone wanting resilency with CIDR space would need to beg for a class-C sized CIDR chunk.

See above --------------------------------------------------------------------------- And my response to Andy: In message , Andy Linton writes:

On Wed, 11 Sep 2002, Ewen McNeill wrote:

...

I'm also in touch with clients that would like to do this [advertise their blocks to multiple providers for resiliency]

I've heard some very interesting discussions about flap damping at the RIPE meeting this week. [...] The important thing to note is that the thing that is damped is prefixes so dual homing may not give you all you hope for if flap damping is in use.

For both the clients I have in mind most of their benefits would be gained in about the first 5 hops or so (ie, within New Zealand), as that is the main market they're serving. So how important flap damping was to that would largely depend on how soon it was applied.

Dean Pemberton and I have been talking with Simon about trying to get WIX and APE whois servers running so that people could start registering routes and AS policy for RPSL use in NZ. Using these to allocate locally scoped private ASes for use on the WIX and APE would be a doddle.

This would definitely be a good thing. RPSL (from your talk at the Uniforum conference) looks like a Good Thing (tm), and a whole lot more sensible than the alternatives (yet more prefix listson nznog!). Scoped private ASes would also solve the immediate problem -- probably for Aaron too (hence my suggestion you mention this on nznog, and/or directly to Aaron).

It seems difficult to believe that the relatively small additional number of prefixes being announced by the enterprises on the WIX is significant.

WIX is worth about 300 prefixes or so on an average day, and "generally" includes the POPs of most NZ providers. For an organisation hosting a lot of content, there's definitely a win for them in sending traffic "directly" to the POPs (and bypassing the ticket counter at their ISP :-) ). If those routes were symmetric, then there'd also be a resiliency win.

The total number of prefixes is around the 250 mark and many of those come from the "providers" anyway. Filtering out the few dozen prefixes that are /25 or greater would seem to have little impact on table size and the kosher ones could easily handled in a prefix-list.

Last I spoke to Simon about it, he was starting to put filters in on the expected prefixes from each peer with the WIX route reflectors -- which would make it possible to have a pretty "exact" set of expected prefixes. There are 27 prefixes in WIX (right now) longer than /24. Some of them are as long as /30s, and there's a bunch of /29s. One of the clients I have in mind has a /27 CIDR block. They're starting to run out of public address space (despite using RFC1918 everywhere it can be used, and lots of NAT), and will probably try asking for more space. But even that more space is likely to be only another /28, another /27, or maybe if they're very lucky one /26. My point here is that while there might not be very many prefixes longer than /25 in WIX now, that's sort of a self-fulfilling prohpehcy, because prefixes longer than /24 (or /23, /22, /21, etc -- I haven't managed to find out what's considered "best practice" by NZ providers) are being filtered out already by lots of people. So "what's the point?". If the answer is "everyone use RPSL, and persuade people to accept all properly described RPSL lists" then I'm all for it. If the answer is "only providers get to do peering", then that's tantamount to "only people with public ASes get to do peering". And may well lead to a bunch of people chasing public ASes (and provider independant space for that matter) when they don't otherwise need them. Ewen - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog