Tony's draft

[Hank Nussbacher <[e-mail]>]

Interesting idea, Tony.

>   Because all members of an ISPAC are advertising the aggregated shared
>   prefix, any member may attract traffic for portions of the shared
>   prefix that need to be routed to another member.  For this reason, it
>   is essential that all members of the ISPAC be able to route to any
>   other member of the ISPAC without leaving the ISPAC (i.e., the ISPAC
>   is connected).  One way that this requirement could be satisfied is
>   for all members of the ISPAC to be present at a common interconnect.
...
>   By default, simple advertisement of the shared prefix will cause all
>   traffic to enter the ISPAC at the nearest member.  This will only be
>   optimal for sites which have their optimal connection to that
>   neighbor.  In many cases, it would be preferable to determine optimal
>   entry points for components of the shared prefix.  At the same time,
>   it is essential to not advertise all components to the remainder of
>   the network, as this would defeat the aggregation of the prefix.  To
>   preserve aggregation and provide more optimal routing, there is a
>   useful technique which can be borrowed from normal interdomain
>   routing.  In this application, this technique a member of the ISPAC
>   may advertise some of the components of the shared prefix, but the
>   member must insure that the scope of these advertisements is
>   carefully restricted.  The restriction of scope is usually
>   accomplished by administrative filtering and careful coordination the
>   receiver of the advertisements.

Nit: Section 2 and 3 have sentences and paragraphs that belong
together and not in seperate sections.  See above.

Let me give you an example of how I see ISPAC for Israel (or for any
other country): A bunch of ISPs get together as an ISPAC and request
a /14 (you don't specify who we request it from - RIPE, Internic,
IANA?).  They divide it among themselves - a /17 here, a /16 here.
They each advertise this net (lets call it 100.100.0.0/14 for
arguments sake).   We are all interconnected via some local national
NAP or IX.

Problems:

a) I am a devious ISP and when I advertise this net to the Internet,
I do some path prepends and thereby lengthen my path.  Now everyone
will prefer to go via my competitors lines to Israel.  International
bandwidth (T1) costs $600K/yr whereas national bandwidth (T1) costs
$20K/yr.  This way I let my competitor pay for the international
line and I can make do with a much smaller line.

b) I am not so devious but my AS path just happens to be longer than
my competitors when looked at from Sprint/UUnet/MCI (75% of the
Internet according to Boardwatch).  So the packets will just flow
via my competitors expensive international lines rather than mine.
In order to correct, my competitor would have to add prepends to
compensate for my shorter path.  But now, his competitor has a
different path length.  What you need to do is create a center of
the Internet where you measure path length and based on that
measurement, everyone has to add prepends to match the longest AS
path.

An alternative (perhaps this is what you are referring to and I
didn't grok it) would be that each announces the /14 as well as
their own slice, i.e. /17.  Normally the traffic would flow via my
line to my /17 block but if someone moved from me to another ISP
they would not have to renumber but my line would carry their
incoming traffic (I assume outgoing is still via their primary ISP -
you are not clear in that respect).

Problems:

a) I am now providing backup to the other ISP.  ISP X has very
little capital so only maintains one line to the USA (or to a major
in the USA).  I am a large ISP and I maintain 3 lines to the USA for
redundency.  When ISP X's line dies, his /17 is no longer announced
and all his traffic suddenly comes via my line or any of the other
lines in the ISPAC.  ISPAC's would only then be formed by ISPs with
the same amount of lines.  There would have to be ISPACs in one city
for those with just 1 line - and therefore they all want to provide
backup for each other and another ISPAC for those larger ISPs with 2
or more lines.  You have then defeated your purpose since customers
in the same city might very well migrate from a small ISP in ISPAC I
to a larger ISP in ISPAC II.

b) If many customers leave me and move to another ISP since I give
poor service or their prices are cheaper, I still end up carrying
their traffic.  In order for the ISPAC concept to work the amount of
movement between ISPs has to be more or less the same with each ISP
gaining and losing customers of the same amount.  If one ISP loses
most of the customers - he not only loses their revenue but also loses
bandwidth that he can't reclaim.

Hank
IBM Israel