design of a real routing v. endpoint id seperation
This is what I meant by suggesting that source routing was an original attempt at a seperation from routing/locating and endpoint identifiers. You can replace the concept of "source routing" in below with mpls TE, l2tpv3 or any other suitable encapsulation mechanism. The concept is that there would need to be some hierarchy of global routing tables in order for routing to scale. Currently circulated ideas for independence between routing and endpoint identifier have certain modes for operation. A) - end node sends packet to destnode - destnode location is looked up in <SOMEWHERE> <--- Today that is the Global routing tables, indexed by destnode ID - sent to there Most proposals wish to replace/supplement SOMEWHERE with some amorphous protocol and/or some external VeryLargeDatabase. B) - end node sends packet to destnode - destnode location is routed through normative route table lookups - inband signalling provides other alternatives for session/transaction/conversation continuation C) - end node performs locator lookup - end node encaps - destnode decaps This could be as easy as performing IPinIP with srv records and DDNS. This is in direct contrast to all other proposals in that it is much closer to being implementable Today with Todays technology. A chunk of ipv6 space is carved off. This is assigned to multihoming desiring sites. All routers that currently carry Global Routing Tables {can | should } filter this space from their tables completely by default - except the single prefix covering the entire space. 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. * the customer would peer with the VLMrouter, receive no routes and advertise their prefix. * source routing allowed on ingress IF the destaddr is in the multihoming space AND the route-option is the Very Large Multihoming router * source routing is allowed within the ISP network The VLMrouter would make a SOURCE routing decision, putting a source route destination to the customer. * The ISP allows egress source routed packets What this means is that there are 2 tables on the internet, the table that ALL internet routes need have (like today) and the table that only an ISP offering access to multihoming need have. The ISP offering such access would only need, say one box per POP or so. So the scaling problem becomes much smaller in scope. Now only ISP wishing to offer multihoming services need to track the multihoming table. Additionaly, the tables are actually halved, the VLMrouter need not contain the normal internet routes and vice versa. The downside is that an ISP performing as multihoming table hoster would be a magnet for traffic that would possibly transit in and out. Smaller multihoming hosting ISPs would probably try to prepend the prefix mightily, or arrange not to originate it at all, and simply receive prefix source routed from an ISP they connect to who also hosts multihoming hosting AND originates the prefix. No changes to stacks, endpoint nodes or anything else needed. (if source routing still works in ip6?) Some source routing filtering capabilities needed for border patrolling something like this config-if#ip source-routing prefix-list multihoming-prefixes access-group allowed-source-routes Joe
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.
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.
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
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
participants (4)
-
Jeroen Massar -
Joe Maimon -
Michael.Dillon＠btradianz.com -
Owen DeLong