North American Network Operators Group

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

design of a real routing v. endpoint id seperation

  • From: Joe Maimon
  • Date: Thu Oct 20 07:50:36 2005

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.

- 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.


- 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


- 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