North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: design of a real routing v. endpoint id seperation

  • From: Joe Maimon
  • Date: Fri Oct 21 09:24:22 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

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