New subject: BGP Private ASes

11 Sep 2002

      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

Re: BGP Private ASes

Ewen McNeill

Joe Abley

James Tyson

Lin Nah

Andy Linton

Simon Blake

Joe Abley

Simon Blake

Joe Abley

Simon Blake

Joe Abley

Arron Scott

Joe Abley

Philip Smith

tags

participants (8)