[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Geographic aggregation-based routing



In einer eMail vom 10.07.2008 16:48:15 Westeuropäische Normalzeit schreibt bill@herrin.us:
On Thu, Jul 10, 2008 at 9:04 AM,  <HeinerHummel@aol.com> wrote:
> But geographical labelling does, and, it does NOT need any distribution
> mechanism.
I should have added already here: I am not in favor of a BGP-like Routing Table that contains geographical prefixes !!! I am not favoring collecting routes, instead computing/distributing/collecting topological links of different zooming levels. And links can be marked. E.g. "Not for transit". Will say, your example doesn't manifest any problem.
I admit, I still have some problems by going for the "ultimate" which of course is the more hampered by the incremental deployability issue. But your example is not one of them.
 
If you look at the graph on www.hummel-research.de you can see many, many routes to the red destination node which caters for multipath, traffic balancing, QoS/Policy-routing... Why not also inter-domain-wise ?!
By knowing the topology you can do better policy-TE than without. Sure, after you have learnt shortest path, first. And the elimination of the scalability problem is just a side-effect !
 
IMO I do propagate a different school of thought. It will also enable different solutions with respect to rigidity versus compromises. In the past I have seen that the PNNI-architecture was given about 5 years of efforts, although (as I know now) it defeated itself: the hierarchical nodes became bigger and bigger, hence required a node-internal topology :-(. But if you look at GOOGLE MAP examples: that looks marvelous and does inspire to do topology aggregation or, if you want, to compose topologies of mixed zooming levels.
 
IMO, research is about trying.
 
Heiner
 
 
 
 
 
 
 
 
 
 

Heiner,

As I'm pretty sure most everyone else on the list has figured out,
routing based on geographic aggregation results in routing policy
violations in any sufficiently complex internetwork.

Consider the configuration of 8 nodes at:
http://bill.herrin.us/network/geoag.gif

The black lines are network links. The two blue circles represent
geographically proximate areas, that is every node in the same circle
has the same geographic label. The green arrows indicate who pays who
for transit service. Note the absence of an arrow between C and G, and
between B and F: those are unpaid reciprocal peering.

With both BGP and geographical routing, this network is fully
connected. There are announced routing paths leading from each node to
every other node.

With BGP, packets from D to F would travel:

D-C(d pays)-G(e pays)-F(e pays)-E

With geographic routing, they travel:

D-C(d pays)-B(oops!)-F(e pays)-E.

This breaks a critically important part of routing policy! At every
router and on every link, the source, the destination or both must pay
for that packet to be there.

When are you gonna figure this out and move on from geographic
routing? There are a couple  topological aggregation variants which
still hold some possibility but geographic isn't one of them.

Regards,
Bill Herrin


--
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg