Re: design of a real routing v. endpoint id seperation
The way around it is to stop growing the DFZ routing table by the size of the Prefixes. If customers could have PI addreses and the DFZ routing table was based, instead, on ASNs in such a way that customers could use their upstream's ASNs and not need their own, then, provider switch would be a change to the PI-ASN mapping and not affect the DFZ table at all. One way to do this is for two ISPs to band together in order that each ISP can sell half of a joint multihoming service. Each ISP would set aside a subset of their IP address space to be used by many such multihomed customers. Each ISP would announce the subset from their neighbor's space which means that there would be two new DFZ prefixes to cover many multihomed customers. Each multihomed customer would run BGP using a private AS number selected from a joint numbering plan. This facilitates failover if one circuit goes down but doesn't consume unneccesary public resources per customer. This does require the two ISPs to maintain a strict SLA on their interconnects in order to match the SLAs on their customer contracts. The interconnect then becomes more than just a peering connection, it also becomes a mission critical service component. Of course, the whole thing multihoming thing could be outsourced to a 3rd party Internet exchange operator with some creativity at both the technical level and the business level. The IP address aggregate would then belong to the exchange. More than 2 ISPs could participate. Customers could move from one ISP to another without changing addresses. The SLA on interconnects could be managed by the exchange. Etc. --Michael Dillon
Re: design of a real routing v. endpoint id seperation
--On October 24, 2005 10:44:31 AM +0100 [EMAIL PROTECTED] wrote: One way to do this is for two ISPs to band together in order that each ISP can sell half of a joint multihoming service. Each ISP would set aside a subset of their IP address space to be used by many such multihomed customers. Each ISP would announce the subset from their neighbor's space which means that there would be two new DFZ prefixes to cover many multihomed customers. [snip...] Except this completely disregards some customers concerns about having provider independence and being able to change providers without having a major financial disincentive to do so. That _IS_ a real business concern, no matter how much the IETF would like to pretend it does not matter. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgpkFXpytrwxe.pgp Description: PGP signature
Re: design of a real routing v. endpoint id seperation
One way to do this is for two ISPs to band together in order that each ISP can sell half of a joint multihoming service. Each ISP would set aside a subset of their IP address space to be used by many such multihomed customers. Each ISP would announce the subset from their neighbor's space which means that there would be two new DFZ prefixes to cover many multihomed customers. Each multihomed customer would run BGP using a private AS number selected from a joint numbering plan. This facilitates failover if one circuit goes down but doesn't consume unneccesary public resources per customer. [...] I've heard of this from others as well. It seems to be technically feasible, but I am curious about the social aspect: would ISPs actually do this? Would customer's find it acceptable? (given it still locks them to an ISP, now to two of them.) In fact, this is technically feasible right now with IPv4. Does anyone know of a pair of ISPs doing this? John
Re: design of a real routing v. endpoint id seperation
On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said: In fact, this is technically feasible right now with IPv4. Does anyone know of a pair of ISPs doing this? technically feasible and business case reasonable are two different things. Under what conditions does this sort of cooperation with a competitor make sense? pgpQnNfVuZEUb.pgp Description: PGP signature
Re: design of a real routing v. endpoint id seperation
[EMAIL PROTECTED] wrote: On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said: In fact, this is technically feasible right now with IPv4. Does anyone know of a pair of ISPs doing this? technically feasible and business case reasonable are two different things. Under what conditions does this sort of cooperation with a competitor make sense? When your customer demands it and is willing to either pay for it or stop paying you for anything.
Re: design of a real routing v. endpoint id seperation
On 24-Oct-2005, at 11:21, [EMAIL PROTECTED] wrote: On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said: In fact, this is technically feasible right now with IPv4. Does anyone know of a pair of ISPs doing this? technically feasible and business case reasonable are two different things. Under what conditions does this sort of cooperation with a competitor make sense? As a customer, I would prefer to multi-home between ISPs who rarely talk to each other rather than those who are in collusion. From a technical perspective I want the operator-induced failures in each ISP to be as independent as possible; from the business perspective I want them both to fight for my money. Joe
Re: design of a real routing v. endpoint id seperation
the internet model is to expect and route around failure. You cannot stop the last mile backhoes. no, but if your facility is critical, you have redundant physical and layer one exits from it. and you have parallel sites. randy
Re: design of a real routing v. endpoint id seperation
ISPs who wish to connect customers who have allocations from the multihoming space must a) announce the whole space aggregated b) peer with other providers who host other customers As mentioned, this huge aggregate attracts unwanted traffic. It would make more sense if this so-called multi-homing aggregate was to be carved up into smaller aggregates based on the geographical topology of the network. That way, providers whose PoPs are geographically close to each other (in the same city) could use multihoming addresses from the same aggregate. Providers could then choose to only offer multihoming services in those cities where they peer with other multihoming providers. The number of aggregate routes announced mushrooms to about 5,000 because there are that many cities in the world with a population greater than 100,000 people. This geotopological address aggregation will still result in some unwanted traffic but a provider is at liberty to carry more detail internally and hand it off closer to the source. For instance, a provider with PoPs in New York and Paris, could elect to carry all Paris routes in New York in order to shed peer traffic before it crosses the Atlantic. I wonder if the solution to these issues would be facilitated by carrying some additional policy info in a routing protocol. Attributes like ROUTE_COMES_FROM_A_PEER_WHO_SELLS_MULTIHOMING or similar. If there are only 5000 or so peering locations in the world, then perhaps an attribute like ROUTE_HEARD_FROM_PEER_IN_CITY_439 would also be useful. --Michael Dillon
Re: design of a real routing v. endpoint id seperation
On Thu, 2005-10-20 at 07:49 -0400, Joe Maimon wrote: SNIP C) - end node performs locator lookup - end node encaps - destnode decaps This could be as easy as performing IPinIP with srv records and DDNS. There is an 'example possible alternate use' in the following document: http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ayiya-02.txt page 20, section 9.3 which describes something that could be called: - double NAT or: - encapsulation The problem though is that this requires the end-site/host to upgrade on both sides otherwise you loose this special multihoming capability. You need to detect that, which costs overhead etc and of course how do you figure out where the other end is at that moment and how do you know that the path between them is optional and and and a lot more issues :) To repeat: that section is only an 'example possible alternate use' so don't comment on it (except if you find typos or so ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: design of a real routing v. endpoint id seperation
(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 tricksanti-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 ATT number does not go through ATTs 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 toldapparently I mistook the conslusions of the relevant threads. apologies. Owen
RE: design of a real routing v. endpoint id seperation
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. We have nobody but ourselves to blame for this. If we all ran networks that worked as well as our customers demand and didn't have our petty peering squables every full moon, the market wouldn't feel the need to have to dual home.
RE: design of a real routing v. endpoint id seperation
We have nobody but ourselves to blame for this. If we all ran networks that worked as well as our customers demand and didn't have our petty peering squables every full moon, the market wouldn't feel the need to have to dual home. that's the telco brittle network model, make it so it fails infrequently. this has met with varied success. the internet model is to expect and route around failure. randy
RE: design of a real routing v. endpoint id seperation
that's the telco brittle network model, make it so it fails infrequently. this has met with varied success. One way to look at it: the internet model is to expect and route around failure. this has also met with varied success. :-)
Re: design of a real routing v. endpoint id seperation
Neil J. McRae wrote: 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. We have nobody but ourselves to blame for this. If we all ran networks that worked as well as our customers demand and didn't have our petty peering squables every full moon, the market wouldn't feel the need to have to dual home. There is not only the multihoming issue but also the PI address issue. Even if any ISP would run his network very competently and there were no outages we would face the ISP switching issue. Again we would end up with either PI addresses announced by the ISP or BGP by the customer. With either the DFZ continues to grow. There is just no way around it. -- Andre
RE: design of a real routing v. endpoint id seperation
On Fri, 21 Oct 2005, Randy Bush wrote: the internet model is to expect and route around failure. randy That precludes agreement on a definition of failure. In recent weeks we have once again learned that a large fuzzy fringe around any sort of 100% consensus makes life interesting. For instance; was the withdrawal of certain routes from your BGP sessions a failure for you? Was it for superwebhostingforfree.com, who relies on a single provider for transit? matto [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: design of a real routing v. endpoint id seperation
the internet model is to expect and route around failure. You cannot stop the last mile backhoes. Tony
Re: design of a real routing v. endpoint id seperation
There is not only the multihoming issue but also the PI address issue. Even if any ISP would run his network very competently and there were no outages we would face the ISP switching issue. Again we would end up with either PI addresses announced by the ISP or BGP by the customer. With either the DFZ continues to grow. There is just no way around it. The way around it is to stop growing the DFZ routing table by the size of the Prefixes. If customers could have PI addreses and the DFZ routing table was based, instead, on ASNs in such a way that customers could use their upstream's ASNs and not need their own, then, provider switch would be a change to the PI-ASN mapping and not affect the DFZ table at all. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpAxFfvw49rq.pgp Description: PGP signature
RE: design of a real routing v. endpoint id seperation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Neil! On Fri, 21 Oct 2005, Neil J. McRae wrote: If we all ran networks that worked as well as our customers demand... Some demand low price and some demand high availability. No way to please everyone. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDWWiP8KZibdeR3qURAlxDAKCnE8uNK36GKu5wHeuFtR9bID3LMwCeNMV5 Hrp1sFipFeyg4or0SHDv5bE= =KdkD -END PGP SIGNATURE-
Re: design of a real routing v. endpoint id seperation
A customer with a prefix assigned from this chunk has to connect with an ISP who has * a Very Large Multihoming (to handle scaling concerns) router somewhere in its network that peers to other ISP Very Large Multihoming routers. ISP operating a VLMrouter to offer multihoming service to their customers would originate the entire multihoming space prefix to their customers AND to all their peers. These would have ALL the prefixes from the Multihoming Space. So... Let me get this straight. You think that significantly changing the economic model of every ISP on the planet (or at least every large ISP on the planet) is easier than changing the code in every core router? ROTFLMAO Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpBRESUz7vDv.pgp Description: PGP signature
Re: design of a real routing v. endpoint id seperation
Owen DeLong wrote: A customer with a prefix assigned from this chunk has to connect with an ISP who has * a Very Large Multihoming (to handle scaling concerns) router somewhere in its network that peers to other ISP Very Large Multihoming routers. ISP operating a VLMrouter to offer multihoming service to their customers would originate the entire multihoming space prefix to their customers AND to all their peers. These would have ALL the prefixes from the Multihoming Space. So... Let me get this straight. You think that significantly changing the economic model of every ISP on the planet (or at least every large ISP on the planet) is easier than changing the code in every core router? ROTFLMAO Owen ISPs who wish to connect customers who have allocations from the multihoming space must a) announce the whole space aggregated b) peer with other providers who host other customers 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. If you are referring to the affect that this will attract unwanted traffic, that would be considered a COB. 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.
