Re: Tony's draft

[Yakov Rekhter <[e-mail]>]

Hank,

> 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.

Alternatively ISPs within an ISPAC that connect the ISPAC with
the rest of the Internet would need to account for traffic they
carry towards each ISP within the ISPAC, and charge each of these
ISPs based on the amount of traffic.
  
> 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).

If you wouldn't require to renumber, then (as you correctly observed)
your line would carry incoming traffic for customers in other ISPs.
So, that would defeat the purpose of announcing /17. And if you
require to renumber, then that would defeat one of the stated
advantages of ISPAC - "help reduce the need for renumbering".

> 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.

All that goes back to the issue of cost recovery for the links between
an ISPAC and the rest of the Internet. One could either assume that an
ISPAC is composed of similar ISPs, or assume that ISPAC members who
provide connectivity to the rest of the Internet would charge other
ISPAC members based on the amount of traffic carried into the ISPAC.
Further observe that the former (assuming that an ISPAC is composed of
similar ISPs) has its own problem, as even if at some point in time
this may be true (e.g., at the point when an ISPAC is formed), this is
condition is unlikely to be preserved. This suggests that accounting
for inter-ISPAC traffic and charging individual ISPs within an ISPAC
based on that traffic may be the only possible alternative. But that
brings a whole set of new issues as well...

Yakov.