nanog mailing list archives
Re: design of a real routing v. endpoint id seperation
From: Joe Maimon <jmaimon () ttec com>
Date: Fri, 21 Oct 2005 09:23:11 -0400
(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
Current thread:
- design of a real routing v. endpoint id seperation Joe Maimon (Oct 16)
- <Possible follow-ups>
- design of a real routing v. endpoint id seperation Joe Maimon (Oct 20)
- Re: design of a real routing v. endpoint id seperation Owen DeLong (Oct 20)
- Re: design of a real routing v. endpoint id seperation Joe Maimon (Oct 20)
- Re: design of a real routing v. endpoint id seperation Michael . Dillon (Oct 21)
- Message not available
- Re: design of a real routing v. endpoint id seperation Joe Maimon (Oct 21)
- RE: design of a real routing v. endpoint id seperation Neil J. McRae (Oct 21)
- RE: design of a real routing v. endpoint id seperation Randy Bush (Oct 21)
- RE: design of a real routing v. endpoint id seperation Neil J. McRae (Oct 21)
- RE: design of a real routing v. endpoint id seperation Matt Ghali (Oct 21)
- Re: design of a real routing v. endpoint id seperation Tony Li (Oct 21)
- Re: design of a real routing v. endpoint id seperation Randy Bush (Oct 23)
- What is multihoming was (design of a real routing v. endpoint id seperation) Michael . Dillon (Oct 24)
- Re: What is multihoming was (design of a real routing v. endpoint id seperation) Owen DeLong (Oct 24)
- Re: What is multihoming was (design of a real routing v. endpoint id seperation) Jeroen Massar (Oct 24)
- Message not available
- Re: What is multihoming was (design of a real routing v. endpoint id seperation) Jeroen Massar (Oct 24)
- Re: design of a real routing v. endpoint id seperation Owen DeLong (Oct 20)