design of a real routing v. endpoint id seperation

Fri Oct 21 13:23:11 UTC 2005

(apologies to Owen for CC'ng list, his points are valid concerns that I 
hadnt addressed or considered properly)

Owen DeLong wrote:

>>
> c) Carry a much larger table on a vastly more expensive set of routers
>     in order to play.
> 
>> ISPs who dont wish to connect these customers should feel free not to,
>> and that will have no bearing on the rest of those who do.
>>
> Somehow, given C) above, I am betting that most providers will be in this
> latter category.

Considering that most people who are in favor of multihoming for ipv6 
believe that there is customer demand for it, the market forces would 
decide this one.

Additionally, until there are a few hundred thousand routes in the 
multihoming table, I dont see any more expense than today, merely an 
extra box in the pop. It could be years away that the doomsday table 
growth the anti-multihoming crowd predicts could occur. Only at that 
point would expensive seperate routers be needed.

In fact seperate routers makes the multihoming table very small, at 
least to start with. It would be an implementation detail. An ISP could 
easily start off by simply not announcing the more specifics in the 
prefix space, without the new router systems.

The point is, that the scaling problems multihoming brings would be 
limited to

a) ISP's who want to offer service to customers who want to multihome
b) The system that the ISP runs to provide this service.

This is in contrast to todays mechanism, where customers who want to 
multihome affect everyone who accepts a full BGP feed.

At the time customer demand worldwide demanded seperate routing tables, 
would be the time that ISPs would be able to decide whether the roi 
would be sufficient or not for them to keep their investment.

Such a scheme would be a "money where your mouth is".

You say there is customer demand for multihoming? Well here it is. Lets 
see which ISPs want to implement it and which customers want to pay 
extra (FSVO extra) for it.

In fact, customers who multihome in this way, need not use the same ASN 
space as the rest of the world, just unique to the multihoming table

(that might not work well if ISP's "faked" it by simply not advertising 
the more specifics they carried internally)

This concept brings true hierarchy, and thus scalability, to the routing 
table.

> 
>> If you are referring to the affect that this will attract "unwanted"
>> traffic, that would be considered a COB.
>>
> That too, but, primarily, c).

There are simple ways to minimize this.

1) standard BGP tricks....anti-social to be sure, such as prepending, 
meds......

2) "Transit"-multihoming peering, where you depend more on external 
parties who peer with you on the multihoming plane more "popular" 
advertisement to bring you a higher ratio of traffic you are interested in.

A small multihoming-table-carrying ISP would want to arrange things so 
that he pays a bit mer per (Mn|Gb) from his multihoming-table-peer, but 
does not have to attract large quantities of unwanted traffic from his 
non-multihoming-table peer.

> 
>> In essence, the previous discussion about LNP suggested that telco's must
>> do the same thing, attract unwanted traffic, traffic they must switch
>> right back out of their network.
>>
> Except they don't.  My formerly AT&T number does not go through AT&Ts
> network to reach me just because it was ported.  Read up on how SS7
> actually works before you make statements like this that simply aren't
> true.
> 

So I have been told....apparently I mistook the "conslusions" of the 
relevant threads. apologies.

> Owen
> 